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PREFACE 



The Joint International Conference on FORMAL DESCRIPTION 
TECHNIQUES for Distributed Systems and Communication Protocols, and 
PROTOCOL SPECIFICATION, TESTING AND VERIFICATION 
(FORTE/PSTV'98), is to be held this year at Ecole Nationale Superieure des 
Telecommunications, Paris, France, from 3 to 6 November, 1998. 
FORTE/PSTV'98 is the eleventh/eighteenth, respectively, of a series of annual 
meetings sponsored by the IFIP Working Group TC6/WG6.1 dedicated to 
"Architecture and Protocols for Computer Networks". 

The conference provides a forum for researchers and practitioners from 
universities and industry to meet and to advance technologies in the areas of 
specification, testing, and verification of distributed systems and communication 
protocols. 

A total of 83 papers have been submitted to FORTE/PSTV'98 and all of them 
were reviewed by the members of the Program Committee and additional 
reviewers. The completed reviewers list is included in this Proceedings. Based 
on these reviews, the Program Committee selected 26 for presentation at the 
conference. Three specially invited papers complete the Conference Program, 
with ten sessions : 

• FDTs Extensions (PART ONE), 

• Verification 1 (PART TWO), 

•Test 1 (PART THREE), 

• Methodology 1 (PART FOUR), 

• Methodology 2 (PART FIVE), 

• Verification 2 (PART SIX), 

• Case Studies (PART SEVEN), 

• Test 2 (PART EIGHT), 

• Hardware/Software Development (PART NINE), 

• Real-Time & Performance (PART TEN). 

FORTE/PSTV'98 has received financial support from the European Commission 
to help researchers and students from Central and Eastern European countries to 
participate in the conference. We also gratefully acknowledge the financial 
support from CNET- France Telecom, EDF and Verilog. 

FORTE/PSTV'98 could not take place without the effort of all the PC members, 
reviewers and people participating in the local organization. The editors wish to 
thank all of them. 
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Abstract: Message Sequence Charts (MSCs) are a graphical and textual lan- 
guage for the specification of message passing systems, in particular telecommu- 
nication systems. MSCs are standardised by the Internal Telecommunication 
Union in standard Z.120. Included in the standard is a formal semantics for 
MSCs by means of a process algebra. This semantics covers the complete lan- 
guage of single MSCs but lacks an interpretation for conditions which are used as 
continuation points of MSCs within an MSC document (a collection of MSCs). 

In this paper, we give a process algebraic semantics for basic MSCs including 
conditions, enabling the formal interpretation of entire MSC documents. 

1 INTRODUCTION 

Message Sequence Charts (MSCs) are a widely used formalism for the specifi- 
cation of the communication behaviour of reactive systems. It allows for the 
graphical and textual representation of the communication structure of systems. 
MSCs focus on the temporal ordering of interaction among system components 
by specifying the executable traces of a system. They are for instance used as 
a graphical representation of executable traces of SDL [17] specifications but 
also as a specification language in their own right. The language has been stan- 
dardised in the standard ITU-T Z.120 of the International Telecommunication 
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Union [7]. Communication in MSCs is asynchronous; the synchronous variant 
are Interworkings [15]. MSC-like diagrams have nowadays also been incorpo- 
rated into various object-oriented specification technique, like for instance the 
Unified Modeling Language (UML) [18]. 

In order to give a precise meaning to MSCs and to allow verification, a for- 
mal semantics is needed. In the standard, the semantics of MSCs is given via 
a translation, originally developed in [13], transforming the textual represen- 
tation of MSCs into a process algebra, based on [1], for which an axiomatic 
semantics exists. Other semantics based on Petri-nets or Biichi automata can 
be found in [11, 10, 6]. However, the standard process algebra semantics does 
not capture a specific feature of MSCs called conditions. Conditions are a rudi- 
mentary form of MSC composition: Within an MSC document (a collection of 
MSC diagrams), a condition describes possible continuation points of system 
behaviour. Every MSC describes a part of the interaction behaviour of the 
system, and an MSC ending with a specific condition can be “glued together” 
with every other MSC starting with this condition. This gives rise to a form of 
sequential composition, followed by a choice of follow-up MSCs, which is indis- 
pensable for the specification of infinite behaviour by means of a set of finite 
MSCs. The only semantics incorporating this interpretation of conditions is 
the automata semantics of [11]. The latter, however, presumes finite-stateness 
of the system under consideration, which in our opinion is not a priori fixed, 
given that MSCs are based on asynchronous communication and, even more 
important, conditions easily allow the specification of non-regular behaviour. 

In this paper, we therefore present an alternative proposal for a process 
algebra semantics for MSCs, which is capable of handling the composition of 
MSCs via conditions. Conditions are translated into process names, which are 
interpreted according to the semantics of the MSCs starting with the condition. 
The composition operator used for glueing MSCs together is a form of weak 
sequential composition based on [19], which is essentially sequential composition 
on the level of instances (the MSC equivalent of a sequential process). This 
operator captures precisely the right interplay between sequential composition 
and the choice of the follow-up MSC. 

Apart from communication behaviour, other aspects specifiable in MSCs are: 

Local actions: actions going on within a single instance that do not infiuence 
and cannot be infiuenced by the environment. Our treatment coincides 
with the standard. 

Timer actions: the setting of timers and the resulting timeouts. Since we 
have no timing aspects in our model, and timer actions are local to in- 
stances, their formalisation would coincide with that of local actions (see 
above). For that reason, we ignore timer actions in this paper. 

General ordering: explicit orderings of actions of different instances, by un- 
specified means. We have not attempted to model such arbitrary order- 
ing; in fact, we know of no formal semantics to date. A straightforward 
formalisation would be to use a special kind of communication for this 
purpose and hide it (in a process algebra sense) afterwards. 
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Coregions: segments of a given instance where the ordering of the actions 
is not fixed but may be arbitrarily interleaved. We model this by non- 
synchronising parallel composition, coincident with the standard treat- 
ment. 

Instance creation: the generation of a new instance and its eventual termi- 
nation. We ignore instance creation in this paper; in the conclusions we 
briefiy discuss how it might be integrated, using a technique inspired by 
the standard semantics. 

Instance decomposition: the replacement, within a given MSC, of a single 
instance by an entire sub-MSC, with corresponding redirection of mes- 
sages sent to or received from the refined instance. Because of the consis- 
tency requirements involved, as well as the issue of redirection and various 
other technical questions (not all of which are answered or even addressed 
in the official standard), decomposition is a very complex matter. We in- 
tend to investigate instance decomposition in the future but omit it for 
now. 

More involved structuring mechanisms mentioned in [7], also not modelled 
here, include inline expressions, MSC references and High-level MSCs. A se- 
mantics for the latter has recently been proposed in [14]. High-level MSCs 
involve the explicit composition of basic MSCs in a fiow chart style, as opposed 
to their implicit composition through conditions. The formalisation of sequen- 
tial composition in High-level MSCs in [14] is also based on [19], just as our 
approach, with the difference that we explicitly recognise the localities of the 
MSC instances, whereas they model them indirectly through dependencies - 
which is closer to the formalisation in [19] and more powerful than our locality- 
based approach, but for the purpose of formalising MSCs poses unwarranted 
complications. The combination of the standard basic MSC semantics in [7] 
and the High-level MSC semantics in [14] gives rise to a framework that is 
significantly more complicated than the one we present here. 

In Section 2, we start with a description of MSC documents. In Section 3, we 
present our process algebra with its structural operational semantics. Section 
4 is concerned with a translation of MSC documents into our process algebra. 
Section 5 discusses the correspondence of our semantics with the standard one 
for single basic MSCs according to [13] and shows some algebraic properties 
of our translation. Finally, Section 6 contains conclusions and discusses the 
relation of our work with [14] in somewhat more detail. 

2 MESSAGE SEQUENCE CHART DOCUMENTS 

We start with a brief description of the functionality of MSC documents, as far 
as it is relevant for our approach. According to the ITU-T standard Z.120 [7], a 
Message Sequence Chart document consists of a collection of Message Sequence 
Charts and Message Sequence Chart diagrams (i.e., high-level MSCs). In this 
paper, we merely consider MSCs. They specify communication/interaction sce- 
narios among a set of instances exchanging messages. Instances can be seen as 
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processes residing on different locations. In the graphical charts, the temporal 
behaviour of one instance is written along a vertical axis. The execution of dif- 
ferent instances is assumed to be asynchronous, thus an axis denotes the local 
time of the associated instance running from top to bottom. The behaviour 
of the external environment of a system is modelled as a specific instance in 
MSCs whose time axis is the frame of the MSC. See for instance the MSC Alt2 
in Figure 1, in which an instance communicates with the environment. 



Figure 1: Example: A simple MSC document 






The actions an instance may execute are depicted as follows: Communi- 
cations are denoted by horizontal or diagonal arrows linking the sender of a 
message to the receiver. The message to be sent is written as a name upon the 
arrow. For instance, in the MSC Init in Figure 1, instances i and j exchange 
messages ml and m2. In case a message is lost, the head of the arrow does 
not end at the receiver instance, but in a bullet with the name of the intended 
receiver associated. Vice versa, a message may be spontaneously generated. 
Internal (or local) actions are drawn as rectangles containing the name of the 
action inside; see for instance the action a in the MSC Init. In the ITU-T 
standard Z.120, internal actions are simply called “actions” and describe some 
activity local to an instance. A further class of actions are timer actions; how- 
ever, as mentioned in the introduction, we follow [13] and (essentially) [7] in 
regarding these as special cases of internal actions. 

Instances are assumed to run sequentially. Thus, the order of action occur- 
rences along the time axis specifies a total order of execution for an instance. 
An exception to this rule are so-called coregions^ which specify unordered events 
of an instance. In a coregion, the time axis is depicted as a dashed line. See 
for instance the sending of m5 and m6 in Alt2. 

An important concept for the composition of MSCs are conditions. Graph- 
ically, conditions are represented as horizontally elongated hexagons, with the 
name of the condition inside. Conditions can be shared between instances; a 
condition that is shared by all instances of an MSC is called global A global 
condition is initial if it is the first item of all instances, and final if it is the last. 
According to the ITU standard [7], conditions can be used either for informal 
annotations or for the composition of different MSCs of a document. The lat- 
ter role is reserved for (global) initial and final conditions: a chart ending with 
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a specific global condition can be continued by any other chart starting with 
the same global condition. Thus, conditions determine possible continuations 
of MSCs. Since the standard semantics does not take MSC composition into 
account, it treats all kinds of conditions as empty steps. In this paper, we deal 
with global conditions only; local conditions would still be translated to empty 
steps. 

It is important to note that conditions are not intended as a synchronisa- 
tion device: although they are sometimes referred to as “global states” in the 
standard, there is no requirement that all instances partaking in a condition 
are simultaneously at that point of their time axis. 

Figure 1 shows an MSC document which consists of three MSCs connected 
by conditions. The MSCs describe the interaction between two instances i 
and j. Assume that execution is started at the initial MSC Init.^ The final 
condition c2 of Init is also the initial condition of the MSCs Altl and Alt2; 
therefore, after performing Init either Altl or Alt 2 can be executed. In Altl, 
the condition c2 is also its final condition, which means that this MSC describes 
a loop. 

Events which are not causally related may be executed independently; for 
example, after composing Init and Altl through the condition c2, the output 
event of message m3 and the input event of message m2 are independent, which 
means that they may occur in any order. In particular, since the condition c2 
is not a synchronisation point, there is nothing to prevent the sending of m4 
(by instance j) to occur before the reception of m2 (by instance i). The same 
holds for the input event of m4 and the output events of m5 and m6. 

In the case where there are several “follow-up” MSCs with the same initial 
condition, there is an interesting, subtle issue involved in their composition: 
namely, the choice of the actual follow-up MSC during a concrete run of the 
system. For instance, in Figure 1, after Init has finished m3 can be sent; 
this automatically involves continuing with Altl and rejecting Alt2. Another 
possibility is that either m5 or m6 is sent, deciding the choice in favour of Alt2. 
However, sending m3 and m5/m6 are independent actions, since they occur in 
different instances. Yet the case where instances i and j simultaneously decide 
to send m3 resp. mb/m6 is not a valid system run. The choice between the two 
follow-up charts is apparently taken on a global level. This is an effect that any 
formal semantics has to take into account; for instance, [12] follows precisely 
this solution.^ 

Finally, we want to comment on an issue raised by [12]. In our opinion, 
and consequently in our semantics, MSC documents do not a priori specify 
finite-state systems, even though, of course, finite-state behaviour is a desirable 
property. For a counterexample, consider an MSC over two instances with 



^Note that the standard does not prescribe an unambiguous starting point; rather, single 
MSCs are thought to represent possible fragments of behaviour. 

^Another point of view is that such a global choice is a specification error and should be ruled 
out in advance. However, we are of the opinion that formulating a semantics comes properly 
before deciding whether the specified behaviour is implement able. 
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identical initial and final condition (i.e., a loop) containing just one message 
sent from one instance to the other. The execution traces of this MSC are 
all traces cr over {in{i^m)@j,out{j,m)@i} such that in each prefix of a the 
number of m(z,m)@j’s never exceeds the number of out{jym)@i and finally in 
a the amount of m(i,m)@j’s and out{j,m)@Vs is equal. Clearly, this is not a 
finite-state recognisable language. In fact, we conjecture that it is undecidable 
whether the behaviour specified by an MSC document is finite-state. As in 
the issue of global choice, we feel that the semantics should be well-defined 
regardless of whether or not the behaviour is finite-state. 



Table 2: Textual representation of MSC documents. 



<document> 


:= mscdocument <docid>; { <msc>; 


}* endmscdocument 


<msc> 


:= msc <mscid>; { <inst def>; }* 


endmsc 


<inst def> 


:= instance <iid>; { <event>; }* 


endinstance 


<event> 


:= <comm event > 

1 action <aid> 

1 condition <cid> shared all 






1 concurrent { <comm event>; }♦ 


endconcurrent 


<comm event> : 


:= in <mid> from [found] <address> 
1 out <mid> to [lost] <address> 


<address> 


:= <iid> 1 env 





The relevant fragment of the textual grammar of MSCs is reproduced in 
Table 2.^ The grammar contains the following undefined non-terminals: 

■ <docid>: MSC document identifiers, ranged over by V; 

■ <mscid>: message sequence chart identifiers, ranged over by M; 

■ <iid>: instance identifiers, collected in Inst, such that env ^ Inst. We 
denote Addr = Inst U {env} for the set of addresses, ranged over hy i,j. 

■ <mid>: message identifiers, collected in Mess and ranged over by m; 

■ <aid>: internal action identifiers, collected in Int and ranged over by r; 

■ <cid>: condition identifiers, collected in Cond and ranged over by c,d. 

It should be clear that not every syntactically correct MSC document is ac- 
ceptable: the above discussion contains a large number of “consistency require- 
ments”. In fact, one additionally needs a static semantics for MSC documents, 
for instance in the form of a type system, such that a document is well-formed 
(well-typed) if and only if it satisfies all those criteria. Some of the crucial 
points are: 

■ Outgoing and incoming messages must be matched precisely; 

■ The ordering imposed by messages may not be circular; 



^In fact, the grammar is an adapted version of that in [7], but the syntax it generates is a 
subset of the standard. 
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■ Global conditions (which are the only ones we model) must occur in all 
instances; 

■ All MSCs in a document must have the same set of instances. 

3 THE PROCESS ALGEBRA Cmsc 

We now introduce the process algebra Cmsc into which we will translate MSC 
documents. The basic building blocks are events of one of the following kind: 

■ out{i,m): normal output of m G Mess to z G Addr] 

■ lost{i^m): discarded output of m G Mess to z G Addr; 

■ in{i,m): normal reception of m G Mess from z G Addr; 

■ found{i,m): spontaneous input of m G Mess from z G Addr; 

■ act{r): an internal action r G Int; 

■ a termination event. 

Events of the first five kinds are collected in Evt^ ranged over by e; furthermore, 
Evt^ — Evt U {v^} is ranged over by a. In each case, a@j denotes the event 
a taking place at instance j G Inst^ and a@Inst the collection of all such 
a@j. Additionally, we assume a set of process names Names to allow recursive 
definitions. Cmsc is then given by the following abstract grammar: 

B::=S\e\e@i\B‘B\B-\-B\B\\^B\X\l , 

where A C Evt@Inst and X G Names. The operators have the following 
intuition: 

■ (5 is an empty, non-terminated (i.e., deadlocked) process. 

■ £: is an empty process, terminated at all instances (corresponding to 
“skip”). 

■ e@i specifies an event at instance z, and is, furthermore, terminated at 
all instances except for z. 

■ • specifies weak sequential composition of its operands. It has been intro- 
duced in [19] in a more general setting and we adapt it here to handle 
MSC composition. A similar operator has also been used for Interwork- 
ing composition (which are the synchronous variant of MSCs) in [15] and 
as a sequencing operator on High-level MSCs [14]. The effect is that of 
ordinary sequential composition within each instance, whereas different 
instances are allowed to proceed independently. That is, termination of 
the first operand at a given instance z (signalled by a y@z-transition) 
allows the second operand to perform events a@z but not a@j for j ^ i. 
(It is important to keep in mind that a term may be terminated at one 
instance but not at another, so that termination of a term at one instance 
does not imply the inability to do some real event at another; witness e@i 
above.) 
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■ + specifies a choice between its operands, which is resolved by the first 
non-termination event that occurs. The behaviour with respect to termi- 
nation is somewhat more complex, based on the principles developed in 
[19]: B\ -h B 2 terminates at i if either of its operands does, but the choice 
is only resolved thereby if the other operand does not terminate at i. We 
let XlnGiV denote a choice over all terms Bn where n is out of some 
finite set N; consequently, ^^^0 Bn equals S. 

■ 11^ is a TCSP-parallel composition [2] requiring synchronisation on all 
events in A; that is, the operands may do events e@i G A together (i.e., 
both at the same time) or events e@i ^ A on their own. Moreover, we 
require implicit synchronisation on termination, i.e., events y/@i may also 
only be performed by both operands together. 

■ X e Names stands for the invocation of the process names X. Processes 
are defined by a process environment 9 : Names -> Cmsc^ which is 
assumed to be given. 

■ Finally, ± stands for an empty message pool This is the only really 
non-standard operator in Cmsc\ it is defined especially to model MSCs. 
Message pools will be used for the modelling of the asynchronous commu- 
nication of MSCs using the synchronous communication of Cmsc- Mes- 
sage pools are inspired by the modelling of asynchronous communication 
in of coordination languages; see, e.g., [3]. A message pool is used to 
buffer the sent but not yet received messages. Operationally, this is done 
by generating a parallel m(i,m)@j-event whenever an out{j,m)@i-eyent 
is sent. 

As usual, the formal semantics of Cmsc will be derived via SOS rules generating 
a labelled transition system over Evt^@Inst. We recall the general definition: 

1 Definition. A labelled transition system over a set of labels L is a tuple 
(5, -^,g) such that 5 is a set of states, ->C5xLx5isa transition 
relation and g G 5 is the initial state. 

In our case, the labels are taken form the localised alphabet Evt^@Inst. A 
transition B B’ means that the term B may signal termination of instance 
i, thereby evolving into B'. For instance, a term B not referring to instance i in 
any of its events (and not containing 5) may always signal termination of i; it 
in fact has no information on i and assumes it to be terminated. Table 3 gives 
the structural operational semantics of Cmsc- This gives rise to a transition 
system semantics for each £M 5 C“term. We briefly discuss the intuitive meaning 
of some of the operational rules. The first rule for weak sequential composition 
equals the one for (normal) strong sequential composition: the first process is 
allowed to proceed. The second rule, on the other hand, describes the fact 
that the second component may also execute events at instance i if in the flrst 
component instance i is terminated, as specified by the second rule. For a term 
that only refers to events from one instance i, weak sequential composition 
coincides with strong sequential composition; i.e., the second operand starts 
execution only if the flrst one is completely terminated. 
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Table 3: Operational semantics for C msc 




Choices can be resolved both by normal events and by termination signals 
within one operand, i.e. a term containing choices is terminated if one of its 
components is. This is in accordance with the usual interplay of termination 
and choice; see, for instance, [1]. However, if both operands of a choice may 
terminate for an instance z, the choice is not yet resolved and both components 
execute their termination transition. In this way, we avoid that a choice can be 
resolved by the termination of an instance not participating in an execution. 
For instance, using the rules in Table 3, we can derive (e@l-he'@2) -e"@3 ^ 

(e@l + e'@2) • e rather than (e@l + e'@2) • e"@3 — - ® - ?> e@l • e or (e@l + e'@2) • 
e"@3 e'@2 • 5. 

Process names behave according to their instantiation by 6. 

The semantics of _L shows a process algebraic modelling of a message pool: If 
the pool receives a message from a sender, i.e., the pool performs out{j,m)@i^ 




12 



it stores it for the receiver by evolving into the term m(z, m)@j H 0 ±. Delivering 
the message to the receiver will be done by synchronising on in{i^m)@j] this 
does not cause any interference with the rest of the message pool. The details 
of the semantics of J_ will become clearer in the next section. There we describe 
how MSC documents can be translated into Cmsc- 



4 TRANSLATION OF MSC DOCUMENTS INTO Cmsc 

We assume that the document in question has instances Inst (i.e., all MSCs 
in the document contain definitions of the instances Inst)^ messages Mess and 
conditions Cond] we let Cond C Names, i.e., conditions serve as names for 
recursive processes. For the corresponding process definition 6 see below. We 
let init{M) equal the initial condition of an MSC M, if it exists, and e otherwise; 
likewise, fin{M) equals the final condition of M, if it exists, and e otherwise. 
The translation is defined in Table 4. MSCs, instances and events are mapped 



Table Translation functions. 



[.]doc : <doc> -> 2^"^^ 

[document V; <m>i ; • • • ; <m>„; endmscdocumentjdoc = {[<m>jk]msc | 1 < A: < n} 

[’]msc • ^msc> ^ C-MSC 

[msc M; <i>i ; •••; <i>n; endmscj^sc = { Wpooi 

([<i>l]in»t ||0-*-||0[<i>n] inst) 

) ’fin(M) 

where pool = {m(z,m)@j, out{i,m)%j \ i,j £ Inst,m € Mess} 



[•linst : <inst def> -> Cmsc 

[instance i\ <e>i ; •••; <e>ni 



endinstancejinst = [<e>ijivent • • • • • [<e>n]ev 



[] 



: <event> Cmsc 

[<Ce>]event ~ [^^®^lcomB 

[action = oci(r)@z 

[condition c shared = e 

[concurrent <ce>i ; • • • ; <ce>^ ; endconcurrent]*^^^^. = [<ce>i]*oj 



llo [<ce>„]*„ 



[.]comm : <comm event> Cmsc 

[in m from = in{j,m)@i 

[in m from found j]lomm — f^'^'^d{j,m)@i 
[out m to = out{j,m)^i 

[out m to lost j]lojm = ^ost{j,m)@i 



to £M 5 C-terms and MSC documents to sets of £M 5 C-terms. The following 
abbreviations occur in the table: 

■ Bi ' . . . • Bn, denoting the right-associative weak sequential composition 
of a series of terms Bk for 1 < k < n. The combined term equals Bi if 
n = 1 and e if n = 0. 

■ -Bi II 0 . . . II 0 Bn, denoting the right-associative parallel composition of the 
terms Bk, I < k < n. The combined term equals if n = 1 and e if 
n = 0. 
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denotes the translation of an MSC M of a given document V according 
to Table 4, and Bf^ denotes the sub-term of instance i of MSC M. The 
terms resulting from the translation of V are to be interpreted in a process 
environment 6 t> defined as follows: 

for all c € Cond Bv'- c Einit(M)=c ■ 

In words, the behaviour of a condition equals the sum of the MSCs of which 
it is the initial condition. Since the translation of an MSC ends in the invo- 
cation of its final condition (if any), the “glueing together” of MSCs works as 
planned: after an MSC is terminated, a choice of continuations exists, as deter- 
mined by the condition names. Moreover, since we are using weak composition, 
termination is local to an instance. 

2 Example. For the MSC document in Figure 1 we get the following instance 
and MSC terms: 

5?^^^ — out{j, ml)@i • m(j, m2)@i 

Bj^^^ = in{i,ml)@j • act{a)@j • out{i,m2)@j 

^Aiti _ in[j^rn3)@i • out{j,m4)@i 
Bj^^^ = out{i^ m3) @j ‘ in {i^ m4) @j 

_ out{j^m5)@i II0 out{env,m 6 )@i 
_ in{i^m5)@j ‘ lost{i^m7)@j 

= ailpooi {out{j^m5)@i II0 out{env,m 6 )@i \\0 
in{i,m5)@j • lost{i,m7)@j)) • c3 

Moreover, we get the following process environment: 

ev'.cl ^ (± {out{j, ml)@i • m(j, m2)@z||0 

in{i,ml)@j • act{r)@j • out{i,m 2 )@j)) • c2 
c2 (J. Ilp^^, {in{j, m3)@i • out{j, m4)@i|l0 

out{i,mS)@j • in{i,m4)@j)) • c2 
+ (-L llpoo/ iiout{j,m5)@i II0 out{env,m 6 )@i)\\^ 
m(z,m5)@j • lost{i,m7)@j)) • c3 

c3 S 

It can be seen from the translation that the instances may proceed indepen- 
dently in parallel (except that they have to synchronise on termination) but 
have to synchronise with the message pool on all communication (and termina- 
tion) events. Thus, the role of _L is as described in the previous section: It takes 
the message from a sender by performing a synchronised out{i^ m)@j-event and 
stores the corresponding receive event in{j^m)@i until the receiving instance, 
j, wants to synchronise on that event. 

In Fig. 5 the transition system for our example is given, as derived from the 
structural operational semantics. The states corresponding to the three MSCs 
are marked, as are the states corresponding to the conditions. An interesting 
parts of the behaviour is the region surrounding the state marked c2. 
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■ The global choice between the outgoing out{i,m3)@j- and out{j^m5)@i- 
transitions is as described in Section 2. 

■ Starting from Init, this choice can be taken prematurely in favour of 
out{i,mS)@j, which can already be done before in{j,m2)@i occurs. This 
is the effect of weak sequential composition. 

Other noteworthy aspects are that the event in(i,m4)@j can be executed con- 
currently to the events out{j,m5)@i and out{env,m6)@i^ and that the com- 
bined behaviour may loop around, i.e., is infinite. 

Figure 5: Example: Transition system for the document in Fig. 1. 

cl (Init) 




5 RESULTS 

In this section we discuss two issues concerning our semantics: its consistency 
with the standard semantics of [13], and an algebraic property concerning mes- 
sage pools. 

The standard semantics The standard MSC semantics in [7], based on the 
work of Mauw and Reniers in [13], is also process algebraic. We show consis- 
tency of our semantics with the standard by comparing the resulting transition 
systems up to strong bisimulation equivalence [16]. Since the standard seman- 
tics does not capture continuations via conditions, a comparison can be made 
only for single MSCs and not for documents. 

For the purpose of comparison, we recall the relevant part of [13]. We refrain 
from giving the full semantics but instead focus on the major differences. The 
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Table 6: Operational semantics for additional operators. 



Termination 



Sequential 

composition 

State 
operator 



Bil B2i Bil B2i 
ei {Bi;B2)i 



Bi 



(5i II 52)1 
B2 






B'o 



Bi -B2 ^ B[ -,B2 
am i pool B ^ B' 



B'2 



B\\B2 



Am (5) ^ Am (5') Am (5) 
out{j,m)m E M B 



^ A 









> B' 



\m{B) 






■> — out{j,m)@i{^ ) 



semantics of events is essentially the same up to some renaming. Coregions 
are not handled in [13], but in [7] they are translated into a free-merge of (the 
semantics of) all events in the coregion. The free-merge of AGP (denoted ||) 
coincides with TCSP parallel composition with an empty synchronisation set 
(II 0 above) — except for termination, on which more below. From now on, we 
ignore the differences in the translation of events. 

The major differences start on the level of instances. In [13], instances are 
interpreted as the strong sequential composition of their events, in contrast 
to weak sequential in our semantics. To define the operational semantics of 
strong sequential composition, instead of termination transitions local to in- 
stances (-^/^ above), Mauw and Reniers use a global termination predicate: 
Bl denotes the successful termination of process B. The operational semantics 
are given in Table 6. To avoid confusion, we use ; to denote strong sequential 
composition instead of • as in [13]. 

The second difference concerns the composition of instances into MSCs. For 
modelling asynchronous communication, Mauw and Reniers use a state operator 
Am [1]* This operator plays the role of the message pool in our semantics. 
M is a multiset containing out-events: If \m{B) performs an ou^-event, this 
event is added to the set M. An m-event of B can only be performed if the 
corresponding out-event is an element of M; this element is then removed. 
(We denote addition and subtraction of multisets by + and — , respectively). 
Therefore, the state operator ensures that the sending of a message occurs 
before its receipt. 

The translation function of [13] is given by 
5[msc M; <i>i; •••; <i>„; endmsc]„8c = A0(5[<i>i]inst || • * * I1 5'[<i>n]inst) 
^[instance i; <e>i ; • • • ; <e>„; endinstancejinst = [<e>i]Uent^ • • ‘ 5 [<®>n]Uent 

The function 5[.]inst translates a single instance i into a process term which 
consists of the strong sequential composition of the events performed by i. 
As before, the events are translated by the function [.Jevent given in Table 4. 
The function 5[.]msc translates a MSC into a parallel composition (free merge) 
of the terms resulting from the translation of the instances. Moreover, the 
term is enclosed in a state operator A 0 to achieve the correct causal order of 
corresponding out- and m-events. 
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As mentioned above, we compare our semantics with the standard one up 
to strong bisimulation, where, however, we have to take the different notions 
of termination into account somehow. The natural thing is to consider the 
global termination used in the standard semantics (as indicated by Bi) to be 
equivalent to the termination of all instances {B B for all i G Inst). This 
gives rise to the following definition: 

3 Definition. Two transition systems Ti = for z = 1,2 are called 

bisimilar, denoted T\ ^ T2, if there exists a relation 72. C 5i x 52 such 
that (^ 1 ,^ 2 ) € 71 and whenever (si,S 2 ) G 72. we have 

- Si s[ implies 34:52 4 such that {s^^si^) G Tl\ 

- S2 S2 implies 3 s[:si such that G 72.. 

Note that our operational semantics (Table 3) as well as the standard one (Ta- 
ble 6) fall into the SOS format of [20], and therefore bisimulation is a congru- 
ence. Consistency of the semantics holds for all well-formed MSC definitions, 
which we defined above to mean that for every outgoing message, a correspond- 
ing incoming one is specified as well. Since we are just comparing single MSCs, 
we interpret all process names (i.e., MSC conditions) in the environment 9x> 
where 6v{c) = e (no continuation). 

1 Theorem. Let <i> be an instance definition and <m> a well-formed MSC 
definition. Then [<i>]inst ^ S'[<i>]inst and [<m>]ni8c 5'[<m>]„8c- 

The proof can be found in the full version of the paper [5]. 

Distribution of the message pool Our translation of MSC documents into 
£M 5 C-terms introduces a message pool per MSC: control is transferred from 
one MSC to the next (as directed by the conditions) only if the message pool 
of the first contains no more remaining elements. This does not correspond to 
the actual assumption about the communication structure underlying MSCs, 
where there is a single global medium. Now we indicate that our model is 
equivalent to such a global medium. The crucial algebraic properties necessary 
to show this are the following: 

(5i||p„„,±).(B2|Ul) = (Bi -52)1^1 (1) 

(5i||p„„,l) + (B2lU±) = (Bi+B2)|U± (2) 

The first of these states that communication with an empty message pool may 
be distributed over weak sequential composition. This is valid up to ^ if B\ and 
B2 are well-formed in the sense that they contain as many out {i,m)@j -events 
as m(j,m)@z-events. In fact, (1) is reminiscent of the communication closed 
layers law of [4], which also plays an important role in the work of Janssen and 
Zwiers [8]. The second equation states a similar distribution property for the 
choice operator. 
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As a consequence of these laws, we can give an alternative translation func- 
tion featuring a global message pool rather than local ones to each MSC, by 
replacing the functions [.]doc and [.]msc of Table 4 by the following: 

^[document V; <m>i ; • • • ; <m>n ; endmscdocumentjdoc = {-L I 1 < ^ 

G^[mSC Af ; <i>i ; • • • J > ©ndmscjngc = ([^i^ljinst II 0 ‘ ‘ ‘ II 0 [^i^njinst) ■ flTl{Ad) 

The following theorem states the equivalence of [.] and G[.] 

2 Theorem. Let <m> be an MSC definition. Then _L 

We regard the fact that this equivalence can be shown by relying on the alge- 
braic distribution properties (1) and (2) as evidence of the power of the process 
algebraic approach. 

6 CONCLUSION 

We have presented a structural operational semantics for Message Sequence 
Chart documents based on process algebras. The semantics, which is consis- 
tent with the standard semantics, covers all basic MSC features including the 
use of conditions as composition operators. Instance creation can quite easily 
be mimicked with asynchronous communication. The creating instance sends 
a special message create to the instance to be created which as an initial ac- 
tion has to perform a receive action of the create message (a kind of “await 
creation”). Instance decomposition can be incorporated in a way similar to the 
standard semantics, namely by syntactic substitution in the MSC term. 

The main advantage of our semantics is the conceptually clear modelling of 
the issues termination and sequential composition. Sequential composition of 
MSCs in the context of high-level MSCs, also based on [19], has been given 
in [14]. In contrast to [14], we use a single concept of termination and just 
one sequential composition operator; the latter can be used both on the level 
of instances and for MSCs. Moreover, we have adapted the weak sequential 
composition operator of [19] to the specific setting of MSCs, allowing to replace 
the complex notion of “permission” by a concept of local termination which is 
the natural translation of termination into the area of MSCs. Starting from 
our semantics, it should be easy to develop a semantics for high-level MSCs; 
sequential composition in high-level MSCs is already present here. 

Acknowledgements. We are grateful to Peter Niebert for cooperation in an 
initial draft version of this paper. 
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Abstract 

An Estelle specification describes a system of communicating components (module 
instances). The specified system is closed, i.e. it has no ability to interact with some 
environment. Because of this restriction, open systems can only be specified together 
with and incorporated into an (Estelle) environment. 

To overcome this restriction, we introduce a compatible extension of Estelle, 
called 'Open Estelle\ It allows one to specify open systems (i.e. systems that have the 
ability to communicate with any environment through a well-defined external inter- 
face), as well as thdr formal incorporation into different environments. We define a 
formal syntax and di formal semantics for Open Estelle, both based on and extending 
the syntax and semantics of Estelle. Furthermore, we present a set of tools, including a 
compiler for the automatic generation of implementations directly from Open Estelle 
specifications. 



Keywords 

FDTs, Estelle, extensions of FDTs, semantic model, FDT-based implementation 

1. Introduction 

Estelle [IS097, DeBu89] is a formal description technique (FDT), internationally stan- 
dardized since 1989. An Estelle specification describes a hierarchical system of inde- 
terministic components called ‘module instances’. Every module instance has a well- 
defined external interface, through which it may interact with other module instances 
of the same system. However, systems formally specified in Estelle are closed, i.e. they 
have no abilities for external communication. Because of this restriction, open systems 
can be described formally only together with and embedded into a concrete environ- 
menP' such that the resulting system is again closed in the described sense. This means 



1 . This work has been supported by the Deutsche Forschungsgemeinschaft (DFG) under grant Go 503/4-1 . 
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that the environment has to be known in advance, and that it must already be deter- 
mined when the open system is specified. 

In [GoRoTh96], pragmatic approaches to the specification of systems with the 
ability to interact with pre-existing real-world environments are studied. These 
approaches are based on the use of primitive functions and procedures or pragmatic 
compiler modifications. According to the Estelle standard, these specifications do not 
possess a formal semantics^. Also, the incorporation of systems specified in such a 
manner into a formal context (e.g. another Estelle specification) is not supported by 
these approaches. 

The formal description technique SDL [ITU94] supports the specification of open 
systems syntactically, since it is possible to connect channels to the system boundary. 
Also, open systems are assigned a formal semantics in terms of a set of communicating 
Meta-IV processes. However, communications are purely internal, because signal 
exchange with the environment is not expressed. Furthermore, the composition of open 
system specifications is neither supported syntactically nor semantically. 

The ability io formally specify open systems in Estelle independently of any envi- 
ronment, and to specify their incorporation into different concrete environments, has 
the following benefits: 

• The expressiveness and the abstraction level of Estelle is enhanced. For instance, 
protocol machines can be formally described and analyzed independently of con- 
crete user modules or network modules. Their formal semantics takes all possible 
environment behavior into account, and is not restricted to a single, explicitly speci- 
fied environment. 

• The decomposition of large systems into sets of components is supported. This 
improves the practical development of systems with Estelle, as it allows one to spec- 
ify and analyze system components separately, and to compose them afterwards. 
Also, component reuse is supported, because components are specified indepen- 
dently of their environment. 

• The formal description of an open system can serve as a basis to generate an imple- 
mentation with the ability to communicate with pre-existing environments. Unlike 
the pragmatic approaches mentioned before, the Estelle specification on which the 
implementation is based has a formal semantics. 

In this paper, we introduce a syntactic and semantic extension of Estelle called 'Open 
Estelle', It makes it possible to specify open systems (i.e. systems that have the ability 
to interact with any environment) through a well-defined external interface, as well as 
their incorporation into different environments. In Section 2, we explain the basic con- 
cepts of Open Estelle. Section 3 introduces the syntactic language elements of Open 



2. An environment specified manually or generated with tools like the ‘Universal Test Drivers Generator’ 
(UTDG, [LLM9UNT97]); see Sections 2.2 and 2.4. 

3. Primitive functions and procedures (and also the specification containing them) have no meaning, unless 
a ‘rigorous, implementation independent (e.g. mathematical) definition of the relevant block is supplied by 
the specifier’ (Clause S.2.4.3 of [IS097]). Such a definition may, however, be difficult to obtain for commu- 
nication with some environment realized, for instance, via primitive functions. 
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Estelle. In Section 4, we define a formal semantics for Open Estelle, which is based on 
the Standard"^ Estelle semantics. Section 5 addresses implementation issues, including 
tool support for Open Estelle. 

2. Basic Concepts of Open Estelle 

The main objective of Open Estelle is to provide language support for the formal 
description of open systems and their incorporation into different environments. This 
means that an open system not only has a well defined syntactic and semantic interpre- 
tation independently of its environment, but also as part of a compound system. In the 
following, we introduce some basic concepts of the syntactic and semantic interpreta- 
tion of open systems, and their incorporation in Open Estelle. 

2. 1. Representation of Open Systems 

A basic design decision of Open Estelle concerns the representation of an open system. 
Standard Estelle already possesses an abstraction to describe encapsulated systems 
with well-defined external interfaces and their aggregation into more complex systems: 
modules. Module instances could in principle supply a suitable representation of open 
systems in Estelle: the module header describes the external interface of the module 
instance without regard to its internal description, the module body describes the mod- 
ule instance behavior. 

Note that a module definition describes an open system, while a module instance 
is an open system. At any point in time, a module instance (i.e. an open system) is sur- 
rounded by a collection of other module instances. We call this collection of other 
module instances environment, and we say that the open system is incorporated into an 
environment when placing it into a collection of surrounding module instances. 

Obviously, modules are a suitable and natural means to describe open systems, 
and in fact Open Estelle basically describes open systems as Standard Estelle modules. 
However, in Standard Estelle, a module can only be defined and used inside the speci- 
fication of a closed system. Furthermore, being a fragment of a specification, it has no 
formal semantics. Therefore, based on Standard Estelle, the following aspects have to 
be addressed: 

• syntactic extensions to define modules that describe open systems independently of 
their environment, 

• a formal semantics for open systems independent of their environment, and also as 
part of a compound system, 

• a mechanism to allow other specifications (e.g. specifications that define a specific 
environment) to import the definitions of open systems. 



4. By Standard Estelle, we refer to the Estelle language defined in [IS097], whereas the proposed extension 
is called Open Estelle. 
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2.2. Formal Import vs. Textual Inclusion 

As noted above, the formal description of an open system must have a unique syntactic 
and semantic interpretation for the open system itself, as well as for its incorporation 
into all potential environments. While the semantic interpretation of an open system 
(its 'behavior') depends on the possible interactions with all environments, its syntac- 
tic interpretation should be independent of the incorporating context. In particular, 
internal definitions of any potential environment incorporating an open system should 
not have any impact on the interpretation of the open system or its external interface. 

The following examples show that this requirement rules out solutions that are 
based on simple textual inclusion of open system specifications into environment spec- 
ifications. In these examples, we assume that open systems are defined by an Estelle 
specification fragment^. We then consider the consequences of textually including 
(preprocessor ‘#include’ statement) these fragments into an incorporating Estelle spec- 
ification. 

Example 1: Interference between an imported interface and its importing envi- 
ronment. 

Let the Estelle specification fragment OS define an open system that refers to a 
predefined function, procedure, or type. Furthermore, let Estelle specification S 
redefine this identifier, e.g like ‘integer’ shown in the following specification frag- 
ment: 

SPECIFICATION S; 

TYPE integer = (zero, one, two); (* predefined type integer is redefined in this scope *) 

MODULE M FOR 

include OS (* textually include specification text fragment OS 

END; 

END. 

The textual inclusion of OS into module S.M causes the definitions given inside 
OS to be interpreted in the context of module M, i.e. with a redefined type ‘inte- 
ger’. Since OS refers to the identifier ‘integer’, it will no longer refer to the pre- 
defined type, but to the redefinition. This may have a massive impact on the 
syntactic and semantic interpretation of OS. 

Example 2: Interference between two imported open systems. 

Let the Estelle specification fragments OSl and OS2 define two open systems that 
(by coincidence) define the same identifier (e.g. different types named PDU for 
different ‘Protocol Data Units’). Textual inclusion of both open systems into the 
same context leads to a syntactically incorrect specification, since it contains an 
inadmissible identifier redefinition. 

Obviously, the syntactic interpretation of the definitions given inside the textually 
included open system descriptions depends on the including context and the combina- 



5. e.g., a module definition together with all necessary constant, type, channel and module header defini- 
tions 
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tion of included open system descriptions. This makes the syntactic definition of these 
open systems non-formal. To obtain di formal definition of an open system, it has to be 
interpreted strictly independently of any environment that makes use of it; in particular, 
the name-spaces of different open systems and importing environments must be sepa- 
rated. In Section 3, we will see that Open Estelle avoids these problems, since 

a) the syntactic definitions given inside the description of an open system are inter- 
preted in a unique way, independently of a concrete importing environment (see 
Section 3.1 and 3.2); 

b) the definitions given inside an open system are not included textually, but they are 
imported in a well-defined way; this formal import only grants access to the 
(unique) definitions of the open system (see Section 3.3); 

c) identifiers imported from an open system description are qualified by the name of 
the open system (e.g. ‘OS1::PDU’ and ‘OS2::PDU’ in Example 2); this avoids nam- 
ing conflicts between different interfaces or with identifiers inside the importing 
environment; furthermore, it improves the readability of the specification, since the 
origin of each identifier is explicitly stated (see Section 3.3). 

2.3. Separation between Declaration and Definition of Open Systems 



In Open Estelle, the description of an open system consists of the external interface 
and the internal description, which are textually separated. Both are syntactically inde- 
pendent of any possible environment using the open system. Furthermore, Open 
Estelle environments incorporating an open system only refer to its external interface 
(see Figure 1). 



EXTERNAL INTERFACE 

of open system 




I I textual unit 
1 1 1 1 1 1 B imported-by 



INTERNAL DESCRIPTION 

of open system 



ENVIRONMENT 

incorporates open system 



Figure 1. Independent Descriptions for Open System and Environment. 



An ‘external interface’ declares open systems (i.e. module body declarations) 
together with all necessary underlying definitions (i.e. module headers, channels, types 
and constants; see Section 3.1).^ An ‘internal description’ defines these open systems 
by adding an internal description (see Section 3.2). This separation makes it possible to 
develop and compile open systems and importing environments independently, as soon 
as their common interface has been defined. Furthermore, it supports the separation of 
concerns between open systems and their possible environments. 



6. External interfaces may import other external interfaces and make use of their definitions (Section 3.3). 
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The textual separation between the external interface and the internal description 
of a system is similar to the concepts found in Modula-2 [Wir85]. Also, the distinction 
between a declaration and a definition of a syntactic object is similar to Modula-2, C or 
C++: a declaration defines name and type (i.e. the external interface) of an object, 
whereas a definition adds internal details.^ 

2.4. Semantics of Open Systems 

Open Estelle has been designed to formally describe open systems and their incorpora- 
tion into any environment. Consequently, an open system should have a formal seman- 
tics independent of an environment, and also as part of a compound system. 

The incorporation of an open system into an Estelle environment is already 
semantically covered by the standard Estelle semantics, since the instantiation of an 
imported open system (i.e. of an Estelle module) creates the same module structure as 
the instantiation of a normal (textually included) local child module. This produces an 
intuitive semantics of the application of open systems. Even more, this semantics 
makes it possible to fuse the description of an importing environment and its imported 
open systems into one single specification that is semantically equivalent. If textual 
interferences (see Section 2.2) are excluded (e.g. by appropriate renaming of identifiers 
defined in open systems and their importing environment), the import of an open sys- 
tem can be replaced essentially by a semantically equivalent textually included child 
module definition. In Section 5.1 we will present a tool that implements this fusion. 

An important aspect of Open Estelle is the definition of a semantics for an open 
systems independent of its environment. In the special case of an open system without 
any external interaction points and exported variables, its semantics is identical to the 
semantics of a corresponding (closed) Estelle specification, independent of any con- 
crete environment, since there are no means for interactions with an environment. But 
if the open system has external interaction points or exported variables, a concrete 
environment can interact by modifying exported variables and/or sending messages 
through external interaction points. Since the semantics of an open system can not 
refer to the specific restrictions of a concrete environment, every possible influence 
through the external interface of the open system has to be considered, i.e. every possi- 
ble sequence of messages received through external interaction points and every possi- 
ble modification of exported variables^. If the open system is incorporated into a 
concrete environment, this maximum set of possible interaction is reduced to a subset 
of interactions with this particular environment. In Section 4, we will describe this con- 
cept in detail. 



7. E.g. in C Mnt succ(int n);’ is sl function declaration and Mnt succ(int n) {return n+1 ;}’ its Junction defi- 
nition. 

8. This kind of maximum interaction is also the foundation of the * Universal Test Drivers Generator' 
(UTDG, [LLM91,INT97]). UTDG generates modules that can send or accept any interaction through their 
external interaction points or execute any modification of their external variables. It was developed to simu- 
late unspecified system components during tests of Estelle specifications. But since it does not solve the syn- 
tactic problems presented in Section 2.2, it is not directly suitable for the formal specification of open 
systems. 
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3. The Syntax of Open Estelle 

In this section, we introduce the syntactic extensions of Estelle for the description of 
the external interface of open systems (Section 3.1), the internal description of open 
systems (Section 3.2), and the incorporation of open systems into different environ- 
ments (Section 3.3) through examples. These extensions are based on the syntactic 
concept of modules. The formal definition of the Open Estelle syntax is given in 
[ThGo97a]. 

3. 1 . Interface Description of Open Systems 

The declaration (and thus the external interface) of an open system is given in an 
INTERFACE-DEFINITION residing in a separate textual uniP. An INTERFACE-DEFI- 
NITION is a container for the declaration (not definition) of a set of open systems and 
for all definitions that are necessary to describe their type and thus their external inter- 
face (i.e. module headers, channels, types and constants). 

TYPE tOperand = RECORD x 1 , x2: REAL; END; 

(Result = REAL; 

CHANNEL binaryServiceChannel(user, provider) 

BY user: request(x: tOperand); 

BY provider: respond(y: (Result); 

MODULE binaryOperatorHeader ACTIVITY; 

IP toUser: binaryServiceChannel(provider) COMMON QUEUE; 

END; 

BODY bkaryC^mtor FOR this declares the open system } 

EKTORKAi*; ( 'binaryServicer.binaryOperator' } 

END. { end of interface ‘ binary Se rvice ' } 

Figure 2. Example for an Interface Definition. 

The INTERFACE-DEFINITION is one of the two new start non-terminals of the 
Open Estelle syntax. Interfaces are uniquely defined, independently of any importing 
environment (see Section 3.3). This is important for a formal description of the 
exported definitions. An interface starts with the new keyword ‘INTERFACE’, followed 
by its name. The declaration of an open system inside of an interface is syntactically 
represented by a MODULE-BODY-DECLARATION, which is a MODULE-BODY-DEFI- 
NITION containing the keyword ‘EXTERNAL’ (see Figure 2). This declaration refers to 
a module header that describes the external interface, but it gives no internal descrip- 
tion of the module body. 

Analogous to Standard Estelle, the appearance of the keyword ‘EXTERNAL’ inside 
a MODULE-BODY-DECLARATION of an INTERFACE-DEFINITION leads to a syntac- 
tically correct, but incomplete description. But in contrast to a SPECIFICATION or a 
BEHAVIOR-DEFINITION, where only a textual modification can remove this incom- 



9. Since the Estelle standard does not state a representation for a specification text, we use the term 'textual 
unit" for self-contained syntactic objects (e.g. a specification). In a UNIX environment such a textual unit is 
usually represented as an ASCII-text file. 
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pleteness, the attachment^^ of an appropriate BEHAVIOR-DEFINITION (see Section 
3.2) leads to a complete description of the declared open systems. 

The reader should note that the interface definition itself describes no behavior 
(no transitions) and no state (no variables or control states). Consequently, it is only a 
container for a set of definitions that may be imported by other Estelle components 
(see Section 3.3). It is even possible for an interface definition to import another inter- 
face definition. This allows two (otherwise independent) interface definitions to share 
common definitions such as types, constants and channels (see Figure 5) and therefore 
supports a clean separation of concerns between open systems that refer to common 
definitions. 

3.2. Internal Description of Open Systems 

The internal description of an open system is given by a MODULE-BODY-DEFINITION 
inside of a BEHAVIOR-DEFINITION residing in a separate textual unit. As suggested 
by the term BEHAVIOR-DEFINITION, from an abstract point of view the internal 
description of an open system only determines the behavior of the open system, 
because the syntactic interface is already determined by the interface definition. 

The BEHAVIOR-DEFINITION is the second new start non-terminal of the Open 
Estelle syntax. It begins with the new keyword ‘BEHAVIOR’, followed by its name and 
a reference to its interface (see Figure 3). The definitions of its interface are imported 
implicitly (see Section 3.3). 

BEHAVlOE bmaiyAdder FOE bm^Servw 
BODY t»*iaryD|j0mtor FOR 

( this defines the open system 'binaryService: :binaryOperator’ } 

TRANS 

WHEN toUser.request(x: tOperand) 

BEGIN 

OUTPUT toUser.respond( x.xl + x.x2 ); 

END; { end of transition-block } 

END; { end of module-body 'binaryOperator;' } 

END. I end of interface 'binary Adder' j 

Figure 3. Example for a Behavior-Definition (see Figure 2). 

A BEHAVIOR-DEFINITION is a container for a set of open system definitions: for 
every MODULE-BODY-DECLARATION of its interface, it contains exactly one match- 
ing^^ MODULE-BODY-DEFINITION, and vice versa. The module body defining the 
open system can make use of all (Open) Estelle constructs for module bodies in its 
internal description, for example, it can be sub-structured into child modules and it can 
even import and use other open systems. This supports a very flexible internal structur- 
ing of open systems. 



10. The attachment of a BEHAVIOR-DEFINITION to an INTERFACE-DEFINITION is a matter of the 
interpreting context, since this operation involves different textual units (e.g. UNIX text-files). 

1 1 . They have the same name and refer to the same header-definition. 
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3.3. Incorporation of Open Systems into Open Estelle Environments 

To be able to incorporate an open system into an environment specified in Open 
Estelle, the interface that declares this open system has to be imported into this envi- 
ronment. The import of an interface is described syntactically by an IMPORT-STATE- 
MENT inside either a specification, a module-body, an interface, or a behavior- 
definition (we will refer to each of them as importing environment). An IMPORT- 
STATEMENT consists of the new keyword ‘IMPORT’, followed by a list of identifiers 
(see Figure 4), which uniquely identify the imported interfaces with the respective 
n ames. 

SPECIFICATION test; 

imports definition of interface ' binary Service ' } 

MODVAR mv: binary Service: :binaryOperatorHeader; 

INITIALIZE 

BEGIN 

/ create open system by instantiating module ‘binaryService: :binaryOperator’ : } 

INIT mv WITH 

/ the open system can now be handled like a regular module-instance ) 

END; 

END. I end of specification 'test’ } 

Figure 4. Example for the incorporation of an open system (see Figure 2). 

The import of an interface defines a qualified visibility in the importing environ- 
ment for all definitions of the interface. This includes (apart from constants, types, 
channels and module headers) also the open systems declared inside the interface. 
These definitions can be referred to by means of their qualified name, which consists of 
their unqualified name (given in their definition), preceded by the name of their defin- 
ing interface and the new symbol For example the identifier ‘binaryService::binary- 
Operator’ refers to the definition of ‘binaryOperator’ inside the interface ‘binaryService’. 
The reader should note that since the interface identifier uniquely identifies an inter- 
face, and since the unqualified name is unique for this interface, every qualified identi- 
fier is globally unique. 

The open system itself is originated when a new instance of its describing mod- 
ule-definition is created by an appropriate INIT-statement (see Figure 4). It is possible 
to dynamically create several open systems (i.e. module instances) from the same open 
system description (i.e. module). In general, all mechanisms that Standard Estelle 
offers for the handling of instances of locally defined child-modules can also be used 
with respect to an open system, including communication with the open system or its 
termination. 



12. By 'incorporate', we refer to the embedding of the open system (i.e., the instance) into the instance of an 
environment. This should be distinguished from a textual inclusion of the description of the open system into 
the description of an Open Estelle environment. 

13. The unique mapping of an interface-identifier to an interface is a matter of the interpreting context, since 
this operation involves different textual units (e.g. UNIX text-files). 
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Importing an interface is not only useful to get access to the open systems defined 
inside of it. Since the import of an interface makes all of its definitions visible to the 
importing environment, interfaces are also useful for the global definition of constants, 
types, channels and headers, which can be used in different specifications, behavior 
definitions, or even interfaces. This aspect is particularly important for the separation 
of concerns of independent interfaces with common definitions; e.g. in Figure 5 the 
separated interfaces intC and IntS declare open systems with compatible external inter- 
action points. This is possible because both of them import interface intA, which con- 
tains the appropriate channel-definition. Thus it supports the specification of a system 
of interfaces that exactly models the type dependencies of the global system. 



implicit 

import 




BEHAVIOR behC FOR inlC; 




hi (clicni) 



SPECIFICATION Spec; 
IMPORT fntCjmS; 





intA::ch 


L_J 


(clienl) (server^ 






BEHAVIOR behS FOR IntS; 



Ch {SCrv^rrifi 



Figure 5. Multiple interfaces with common definitions. 

3.4. Module Attribution 

The module attribution rules given in Clauses 5.2.1 and T.3.6.2 of [IS097] are not 
directly suitable for the application in Open Estelle, since they only relate to the textual 
nesting of modules. Therefore, in [ThGo97a] we introduce extended module attribu- 
tion rules, which imply the same attribution scheme for the dynamic module instance 
tree as the original rules. It is possible to specify both, open systems that contain one or 
more subsystems'"^ (which can be incorporated into un-attributed environments) and 
open systems that can be part of other subsystems. In particular, it is possible to specify 
open systems that can be incorporated into arbitrarily attributed importing environ- 
ments. 

4. Semantics of Open Estelle 

Estelle qualifies as a formal description technique, meaning that it has both a formal 
syntax and a formal semantics. The proposed language extension should therefore 
cover both aspects to preserve the formality of Estelle. In order to define the meaning 
of Open Estelle specifications formally, we have devised a semantics that models the 



14. With the term 'subsystem ’ we refer to instances of system modules. 
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interaction between an open system and an environment. More precisely, the semantics 
captures all potential behavior of an open system in all possible environments; this 
potential behavior is reduced when the open system is incorporated into a specific envi- 
ronment. 

In the following, we describe this semantics in some detail. We argue why despite 
the different nature of Open Estelle it is feasible to define its semantics in terms of 
computations as in the Standard Estelle semantics. This has the advantage that the lan- 
guage extension is fully compatible with Standard Estelle, and that it will be straight- 
forward to argue why the incorporation discussed above is complete and sound. 

4. /. Formal definition of the Open Esteile semantics 

According to the Estelle standard [IS097], the semantics of a Standard Estelle specifi- 
cation SP is formally given by the set of its computations. Computations are sequences 
<sito,sit|,....> of so-called global situations, where sito is initial, and for all j>0, sitj is a 
possible next global situation of sitj.j with respect to the next-state relation. Roughly 
speaking, a global situation comprises the local states of all module instances (state of 
input queues, values of local variables, module structure, connection structure) and sets 
of transitions selected for firing. A next global situation results from either firing a pre- 
viously selected transition, or selecting a set of transitions according to certain rules. 
Thus, an Estelle specification defines a transition system (S, 5), where S and 5 are 
related to the set of global situations and the next-state relation, respectively. Concur- 
rency is modeled by interleaving. 

We will now generalize this semantics to capture the meaning of Open Estelle 
specifications. In particular, the formal semantics of Open Estelle will reduce to the 
Estelle semantics in the special case of a closed system, namely systems without exter- 
nal interaction points and without exported variables. 

To start with, let us consider the definition of the next global situations and com- 
putations as given in the Estelle standard: 

Definition 1 {next global situations, computation’. Clause 5.3.4, [IS097]): 

Given a global situation, sit = (gidgp; Ai,...,Ajj), the set of next global situa- 
tions is described as follows: 

(a) For every i = 1 ,...,n: if Aj = 0, then for every AS(gidsp/Sj) e AS (gidsp/Sj), 
(gidsp; Ai,...,AS(gidsp/Sj),...,A^) is a next global situation of sit. 

(b) For every i = l,...,n: if A| ^ 0, then for every t g A|, 

(t(gidsp); Aj,...,Aj\{t},...,Aj^) is a next global situation of sit. 

NOTE — There are as many next global situations of the situation sit as there are possible 
choices of next transition t (and its results) in case (b), and different empty sets Aj in sit, for the 
case (a). In addition, in case (a), all possible choices of the set AS resulting from non-determin- 
ism of each component process in the system rooted at Sj must be taken into account. 

NOTE — !...] 

A sequence of global situations of SP, sitQ,siti,...,sitj,... is called a computation ofSP if 
and only if sito is initial, and for every j > 0, sitj is one of the next global situations of 
sitj.i as described by (a) or (b) above. 
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For each subsystem represented by a system module, either a new set of fireable 
transitions is selected, or an already selected transition is executed. If a transition t of 
module instance P is fired, the outputs of t are transmitted to the destination queues as 
part of the global effects of t, as defined by transmissionp(gid’ 3 p), where gid’sp E 
[t]p(gidsp) (see Clause 9.5.4, [IS097]). If, for a given output, no destination queue is 
defined, then the interaction is discarded. Note that all destination queues are repre- 
sented in gid’sps therefore, all global effects of t can be applied directly. Furthermore, 
exported variables may be modified as part of the local effects of t. 

In order to generalize this definition to Open Estelle specifications, we have to 
incorporate the interaction of the specified system into its environment in some way. 
More specifically, we have to incorporate receptions from, transmissions to, and modi- 
fications of local variables by the environment. Recall that these interactions occur 
through external interaction points and exported variables. However, as the environ- 
ment is not determined, we have to consider all possible environments, which amounts 
to taking all possible receptions, transmissions, and assignments to exported variables 
into account^^. We will first deal with receptions from the environment and assign- 
ments to exported variables by extending Definition 1. Then, we will address transmis- 
sions to the environment. 

All interactions with the environment occur through external interaction points 
and exported variables. As these interaction points and the exported variables are 
typed, the set of interactions that may be received from the environment by module 
instance P through an external interaction point ip (receivep(ip), see Clauses 9.3.1 and 
9.4.3, [IS097]), as well as the set of values that may be assigned to an exported vari- 
able e are determined. To take all environments into account, we model all possible 
receptions and assignments by extending the set of next global situations as defined 
below. Furthermore, we consider global situations w.r.t. an arbitrary module instance P, 
not just the specification SR 

Definition 2 {next global situations, potential computation; Open Estelle): 

Given a global situation, sitp = (gidp*, Aj,...,Aj^), of a module instance P, the 

set of next global situations is described as follows: 

(a) For every i = l,...,n: if Aj = 0, then for every AS(gidp/Sj) € AS*(gidp/Sj): 
(gidp; Ai,...,AS(gidp/Sj),...,Aj^) is a next global situation of sitp 

(b) For every i = l,...,n: if Aj ^ 0, then for every t e Aj: 

(t(gidp); Aj,...,Aj\{t},...,An) is a next global situation of sitp 

(c) For every gidp’ € env_mod'^(gidp): (gidp’; Aj,...,A^) is a next global situation 
of sitp env_mod is defined as follows^ 



15. Note that the effects of a ‘terminate’ or ‘release’ statement referring to the open system have no impact 
on the set of computations. In this paper, for reasons of simplicity, we do not consider the effects of ‘attach’ 
and ‘detach’ statements of the environment involving (directly or indirectly) external interaction points of 
open systems. Also, for the same reasons, we do not consider the effects of connecting two external interac- 
tion points of the same open system. 

16. We assume that the type of e is well-defined, i.e. its declaration does not include type-identifiers associ- 
ated with the ‘...’ construct. 
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(cl) For every ip € EIPp: for every € receivep(ip): 

receivedp(gidp <m,V|,...,V|j>) € env_mod(gidp). 

(c2) For every e e EV-idj^, where P e INST(M,B,E), and e is of type T: 
for every v €E(T): assignp(gidp e, v) e env_mod(gidp). 

NOTE — sitp = (gidp; A|,...,A„) is the global situation of module instance P, where gidp is 
defined as usual, and each Aj is a set of transitions of the component instances rooted at (a) P, if 
P is attributed, or (P) Sj, if P is not attributed, and S, are system modules. This generalizes the 
definition of global situations to arbitrary module instances. If P = SP, the definition of sitp is 
identical to that of sit in the Estelle standard. 

NOTE — There are as many next global situations of the situation sitp as there are possible 
choices of (a) different empty sets Aj in sitp and possible choices of the set AS resulting from 
non-determinism of each component process in the system rooted at Sj, (b) next transitions t 
(and their results), (c) inputs from the environment and assignments to exported variables of P 
by the environment. 

NOTE — For closed systems (i.e. module instances that have no external interaction points and 
no exported variables) Clause (c) of the definition above has no effects. Consequently, the ‘next 
global situations’ relation given above reduces to the one of Definition 1 . 

NOTE — EIPp is the set of external interaction points of instance P (Clause 9.4.3, [IS097]). If 
P = SP, then EIPp is empty, and no inputs will be received from the environment. EV-idj^ is the 
set of exported variables of P as declared in its module header M (see Clause 9.4.1, [IS097]). If 
P = SP, then no exported variables are defined. If EIPp and EV-id^ are both empty. Definition 2 
is equivalent to Definition 1 of the Estelle standard. 

NOTE — receivep(ip) is the subset of Interactions (Clause 9.3.1, [IS097]) that the instance P 
can receive through interaction point ip (Clause 9.4.3, [IS097]). receivedp(gidp) is obtained 
from gidp by replacing s’.ie(ip’) by append(<ip’,ip,m,Vi, ..., V|^>, s’.ie(ip’)), where downat- 
tach(ip) = ip’, ip’ in EIPp>, and s’ is the local state of P’ (see Clause 9.5.4, [1S097]). This 
includes the special case that ip is not attached, i.e. downattach(ip) = ip. 

NOTE — assignp(gidpse, v) is a new gid of P where the difference with gidp is expressed by 
s.Loc(allocB(e)) := v, where s is the local state of P (see Clause 9.5.4, [IS097]). 

A sequence of global situations of P, <sito,siti,...,sitj,...> is called a potential computa- 
tion ofP if and only if sitQ is initial^^, and for every j > 0, sitj is one of the next global 
situations of sitj.j as described by (a), (b), or (c) above. 

Compared to the Standard Estelle semantics, there are two important differences. 
The first difference concerns the definition of global situations sitp for arbitrary module 
instances P, i.e. not only for the distinguished module instance SP as in Definition 1. In 
order to model the execution of an open system, we generalize the notion of global sit- 
uation by combining gidp with sets of transitions selected for execution. 

The second difference concerns the reception of interactions from the environ- 
ment and the assignments to exported variables of module instance R This is described 
by the transitive closure of a function env_mod in (c). Interactions can be received 



17. The function env_mod: EIPp->^(EIPp) defines a relation env_modp={(x,y)GEIPpxEIPp I 
y€env_mod(x)}. Let env_modp'‘‘ be the transitive closure of env_modp. Then the function env_mod‘'’: 
EIPp->|c>(EIPp), x->{yGEIPp I (x,y)eenv_modR‘^} defines a transitive closure of function env_mod, i.e. the 
result of one or more consecutive events as described in (cl) and/or (c2). 

18. The initial global situations of an open system take into account all possible actual module parameters 
and all possible modifications by the environment according to (c) above, which may take place during the 
execution of a transition executing the init-statement of the open system. 
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through and only through the external interaction points of module instance P, as 
expressed in (cl). Note that env_mod ranges over all ip E EIPp and all 
E receivep(ip). Thus, all possible environments are taken into account. If an external 
interaction point of P is attached, then any reception is appended to the destination 
queue at the end of the attach chain. Assignments to exported variables of module 
instance P are expressed by (c2). Note that env_mod ranges over all e e EV-idjyj and all 
V €E(T), where e is of type T. Thus, again, all possible environments are taken into 
account. 

Since the behavior that is described by the definition of the next global situation 
may in general only occur when the open system is composed with some environment, 
we use the term potential computation of P to denote a sequence of global situations 
satisfying the aforementioned condition. The reason is that in our definition, the behav- 
ior of the environments as captured by (c) does not yet exist. Once the environment is 
completely determined, the set of potential computations is reduced to a set of compu- 
tations in the sense of [IS097]. This is, for instance, the case if we consider a closed 
system. Here, the next global situations are completely described by (a) and (b), which 
gives evidence that the semantics of Open Estelle is indeed compatible with the seman- 
tics of Standard Estelle. 

Having dealt with receptions from the environment and assignments to exported 
variables, we will now address transmissions to the environment. In the Standard 
Estelle semantics, all outputs of a transition t of P are collected in the local state com- 
ponent s.out as the result of its local effects defined by [t]p(s) (see Clause 9.6.6.S, 
[IS097]). The function transmissionp then defines the global effects by appending, in 
the same order, the elements of the sequence s.out to the destination queues (Clause 
9.5.4, [IS097]). If for some output at interaction point ip, there is no destination queue, 
i.e. linked(ip,gidsp) is false, then that output is discarded (see Clauses 9.5.3 and 9.5.4, 
[IS097]). 

The treatment of transmissions in Open Estelle directly follows the Standard 
Estelle semantics. If the destination queue of an output belongs to the open system, the 
meaning of a transmission is just the same. However, if the destination queue is outside 
the open system, i.e. an output is made at some external interaction point of the root 
module P, or at some interaction point that is attached to it, then the output leaves the 
open system^^. This means that the effects of the output on a possible environment are 
not visible in the open system, and therefore not represented in its state. Transmissions 
to the environment can therefore be modeled by discarding the corresponding outputs. 
As this is already handled by the definitions in [IS097] (see Clauses 9.5.3 an 9.5.4), 
the definitions of the Standard Estelle semantics can be used^^. 



19. As already noted above, we do not consider the effects of connecting two external interaction points of 
the same open system in this paper. 

20. To be precise, the functions sentp^ received^ and transmissionp have to be applied to gidp», where P’ is the 
root module instance of the open system, instead of gidsp (see Clause 9.5.4, [IS097]). 
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4.2. Completeness and Soundness of the Open Estelle Semantics 

As already noted in Section 2.4, the semantics of the incorporation of an open system 
into an Estelle environment is reduced to the Standard Estelle semantics by construc- 
tion, since the instantiation of an imported open system (i.e. of an Estelle module) cre- 
ates the same module structure as the instantiation of a normal (textually included) 
local child module. It remains to show that the semantics of an open system on its own 
as defined in Section 4.2 is correct and sound. 



Pa 






Pb 





Figure 6. Open systems Pa and Pb. 

If we consider the semantics of open system Pb on its own in comparison to its 
incorporation into an (open or closed) environment Pa (see Figure 6), module Pa par- 
tially (if open itself) or completely (if closed) determines the environment of Pb. Com- 
pleteness of the Open Estelle semantics means that the potential computations of Pa, 
when ‘projected onto’ the incorporated Pb, are a subset of the potential computations 
of Pb on its own. In other words, the computations of the open system Pb are reduced 
when it is incorporated into some environment. Soundness means that only potential 
computations are defined for Pb that are possible in some environment Pa. The proof of 
these properties is addressed in [ThGo97a]. 

5. Implementation Issues 

Estelle specifications do not only describe systems formally, they can also serve as a 
basis for an automated implementation. Several tools for the automatic implementation 
of Estelle specifications are currently available (e.g. EDT [Bud92], PET/DINGO 
[SiSt93]). Consequently, the automatic creation of implementations directly from spec- 
ifications is also an important objective of the extension of Estelle, especially since it is 
just the openness of systems described with Open Estelle that establishes a well- 
defined relationship with their implementations: open systems formally specified with 
Open Estelle can be implemented with the ability to interact with real-world systems 
(such as operating systems, communication networks or applications) through their 
well-defined external interfaces and with a well-defined semantics. This opens the pos- 
sibility for a direct practical incorporation of formally specified open systems into real- 
world environments. 

5.1. Tool Support 

To create a platform for practical experiments, we have developed a tool set for the 
processing of Open Estelle sources. The front end of this tool set is a compiler that 
translates Open Estelle sources (i.e. interfaces, specifications, and behavior-definitions) 
into a binary intermediate form, which can be processed by the other tools. This front 
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end was developed out of the existing Estelle compiler front end PET (‘Portable Estelle 
Translator’, [SiSt93]), 

Further, we have developed the experimental Estelle Compiler {XEC, [ThGo97b, 
ThGo98, The98]), a completely new optimizing code generator for Estelle and Open 
Estelle, which creates C++-code for open systems and importing environments inde- 
pendently of one another (see Figure 7). It is possible to compile these components 
separately and to delay the ‘fusion’ of open systems and their environments to the 
moment of linking the created machine-object-files into an executable. The compiled 
open systems can be used also by hand-crafted environments and therefore incorpo- 
rated into and communicating with real-world environments. 





Figure 7. independent compilation of open systems and a compatible environments. 



Another Open Estelle tool supports the textual embedding of a set of open sys- 
tems into an Open Estelle environment that incorporates them (see Section 2). This 
method finally leads to an equivalent closed Standard Estelle specification, which 
includes the formerly open systems in form of local module bodies (see Figure 8), The 
tool enables the application of existing formal methods for Standard Estelle to systems 
consisting of a set of Open Estelle descriptions. 



import 




textual embedding 



SPECIFICATION test, 
IMPORT pm\ 




Figure 8. Embedding of an open system into a compatible environment. 
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5.2. Case Study 

As a case study for the practical use of Open Estelle and of the tools presented above, 
we have split an existing, relatively large Estelle specification (more than 7500 lines of 
specification text) of the Xpress Transport Protocol (XTP, [XTP95]) into a set of open 
systems specified in Open Estelle. We have incorporated the XTP protocol machines 
into different Open Estelle and real-world environments, and with different client and 
network implementations without having to re-compile the generated machine object 
file (see Figure 7). 

In particular, it is not necessary to re-compile the whole system after a modifica- 
tion that only affects parts of the system. In our case study the relatively complex XTP 
protocol machine was specified as open system, independently of the application con- 
text (e.g. specification ‘test’ in Figure 7) that import it. After a modification of the 
application context (including all user and network modules), only the context had to 
be re-compiled. This reduced the turnaround-times significantly: the re-compilation 
and linking of specification ‘test’ took less than 10 seconds^^ (1.0 seconds PET/XEC, 
5.8 seconds g++, and 3.0 seconds linking). This is an effective speedup of factor 13 
compared to the otherwise necessary complete re-compilation of the original Standard 
Estelle specification with the textually embedded XTP protocol machine (17.1 seconds 
PET/XEC, 1 10.0 seconds g++, and 4.6 seconds linking). 

The case study demonstrated some of the benefits of Open Estelle for the specifi- 
cation of large systems: one single compilation of the relatively complex protocol 
machine can serve all implementations of Estelle or real-world environments that 
incorporate it. A further structuring of the XTP protocol machine itself into smaller 
open systems additionally supported the maintenance and development of the protocol 
machine, because it simplified the individual compilation units, shortened the turn- 
around times after local modifications of components of the protocol machine and clar- 
ified the type dependences between the components. In particular, it led to a clean sep- 
aration between private definitions of a module and definitions that are exported to the 
former child modules. 

6. Summary and Outlook 

In this paper, we have introduced an extension of Estelle, called 'Open Estelle'. It 
allows one to specify open systems and ihcir formal incorporation into different envi- 
ronments. We have defined a. formal syntax and a formal semantics for Open Estelle. 
The extension is compatible with Estelle both syntactically and semantically, i.e. 
Estelle is a subset of Open Estelle. In particular, the formal semantics of Open Estelle 
reduces to the Estelle semantics in the special case of a closed system. Furthermore, 
we have developed a set of tools supporting Open Estelle, including the new code gen- 
erator XEC (experimental Estelle Compiler) that creates efficient implementations of 
open systems, which can be incorporated into different Open Estelle and hand-crafted 



21. Platform: Sun SPARCstation 20, Solaris v2.5, PET v2.0, XEC vl.l4, g++ v2.8 (without optimizations) 
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environments. We have demonstrated the use of Open Estelle and of our tools by 
means of a case study with the Xpress Transport Protocol. 

There are some aspects of Open Estelle that need further consideration. An 
important issue that is directly related to the Estelle semantics is the validation of cor- 
rectness, based on an implements-relation. We expect that the Open Estelle semantics 
will give rise to an abstract semantics in terms of input/output-behavior, which may 
serve as a basis for a correctness notion. We plan to investigate this issue in more 
detail. 
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Abstract: 

This paper presents a graphical representation for the Formal Description 
Technique Estelle, which has up until now been restricted to a textual syntax 
based on the general programming language Pascal. The graphical syntax and 
semantics of the representation are fully descriptive of a general Estelle system 
and complies with the ISO Estelle standard [IS097]. 

This representation aims to become a standard technique for formally spec- 
ifying and simultaneously documenting concurrent, communicating systems. 
Conventions introduced in existing graphiczil Estelle tools are re-used, as are 
graphical concepts which have become familiar through widespread use of the 
similar Specification and Description Language (SDL). 

In addition, we present a syntax-directed editor based on the graphical syn- 
tax. The editor enables practical application of the graphical technique, by 
translating a graphical description to the equivalent textual form which can be 
input into existing Estelle tools. The reverse function makes it possible to view 
and navigate existing textual Estelle specifications more effectively. 
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1.1 INTRODUCTION 

Estelle is a well-defined Formal Description Technique (FDT) used for defin- 
ing and analyzing concurrent, communicating systems. It shares this function 
with a number of other techniques, including the Specification and Description 
Language [ITU89], LOTOS [BB87] and Petri-nets [Pet62]. 

Estelle was specifically developed by the International Standards Organisa- 
tion (ISO) for the purpose of describing the protocols and services of the Open 
Systems Intercommunication Model [IS094]. It is also an implementation- 
oriented language based on Pascal [IS083] which can be used as a basis for 
reliable protocol and service implementation. Estelle is standardized by the 
ISO and the latest standard ([IS097]) was produced last year. 

Estelle is however considered to be lagging behind other Formal Description 
Techniques such as the SDL, due to its lack of a standard graphical representa- 
tion. SDL which is very similar to Estelle experiences much greater popularity, 
and one reason for this is considered to be the existence of a standard graphical 
notation and support tools for SDL. 

A graphical technique is usually preferable to a textual one due to its intuitive 
and pictorial nature. A graphical representation is able to better structure 
conceptual ideas than pure text, and is closer to the abstract meaning of that 
which is being described. 

In fact, graphical techniques have been in use since long before the develop- 
ment of early digital computers, whose limitations of graphical hardware and 
software forced the development of textual techniques. Modern graphical inter- 
faces have removed this limitation, and graphical techniques have once again 
become popular. 

A graphical technique can be used in two ways in the context of concurrent, 
communicating systems: 

■ to statically define the unique structure specifying the functional be- 
haviour of a system, or to 

■ dynamically describe (as opposed to “define”) the non-deterministic be- 
haviour of the system. 

Techniques which fall into the first class have a formal syntax and semantics, 
and can be used for formally defining systems. This is not true of methods in 
the second class, which can only describe behaviour instances of a system, i.e. 
the results of a static definition. 

In this paper we introduce a standard, definitive graphical technique for 
Estelle which is currently being developed. We refer to this notation as the Es- 
telle/GR (graphical representation), as opposed to the Estelle/PR (phrasal 
representation as defined in the ISO Estelle standard. The Estelle/GR has 
a formally-defined syntax and semantics, and is compliant with the ISO Es- 
telle/PR definition. 

In addition, the second part of this paper presents a prototype editor based 
on the Estelle/GR. 
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The editor makes use of the features of modern graphical interfaces, such 
as multiple, linked windows and virtual scrolling canvases to provide powerful 
manipulation of large graphical documents. 

The editor combines the utility of the graphical technique with the power 
of existing Estelle/PR software tools, by providing translation of the graphical 
document into equivalent Estelle/PR text. The reverse function furthermore 
allows the graphical technique to be applied to existing Estelle/PR specification 
documents. 

1.1.1 Existing Estelle visualisations 

Only two tools exist which attempt to implement graphical techniques for Es- 
telle. Neither of these tools attempts to produce a standardized notation, and 
neither provides the ability to graphically define a general Estelle specification. 

P. Amer et al present GROPE in [NP93, NP90]. GROPE simulates the 
execution of a general Estelle specification graphically. It which uses a descrip- 
tive notation to present the dynamic state of an Estelle system and animates 
changes in this state. It visualizes the structure of the specification using the 
common SDL-like nested box notation, and describes each internal module be- 
havior separately in the form of a simple finite state automaton. We re-use 
some of the abstraction concepts of the GROPE automaton description in the 
Estelle editor. GROPE is not publicly available. 

ASA+ is maintained by Verilog, and is an editor for a non-standard varia- 
tion of Estelle called LSA+. It uses a partially graphical notation which defines 
the internal structure of an individual module using a nested box notation, and 
specifies hierarchical module relationships in a tree form, but specifies internal 
module behavior using a modified Estelle/PR syntax. The usefulness of ASA-f 
is limited by the its non-standard extensions and restrictions, and it is not 
widely used. 

1.1.2 Paper outline 

Section 1.2 of this paper is a brief introduction to the Estelle model, which 
provides a starting point for describing graphical representation and structure 
of the editor. Sections 1.3, 1.4 and 1.5 introduce the main points Estelle/GR 
syntax using the Trivial File Transfer Protocol to provide examples. Section 
1.6 discusses the main functions of the prototype editor, and includes some 
screenshots showing it in use. Section 1.7 concludes. 

Space considerations unfortunately prevent the formal definition of the full 
Estelle/GR syntax and semantics. Interested readers however are welcome to 
contact the primary author for further information. 
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1.2 THE ESTELLE MODEL 

An Estelle specification describes a hierarchically structured system of non- 
deterministic sequential components exchanging messages through bidirectional 
links between their ports. 

Each component is an instance of a generic module definition. A generic 
module statically defines a header and several associated body parts and an 
instance is dynamically created from a given header-body pair of a generic 
module definition. 

The header part defines the external communication interfaces of the module 
and specifies the parallel or sequential non-deterministic execution of its child 
modules; the body part defines its internal behaviour and recursively defines 
generic children modules. 

Estelle uses an extended finite state machine (EFSM) paradigm to describe 
module behaviour. Each module body defines an EFSM which receives inputs 
and sends outputs via the communication interfaces of the header. Each tran- 
sition has a set of conditions which must be satisfied before the transition may 
fire, and a set of actions which are executed atomically on firing. 

An Estelle system has a dynamic structure which sets it apart from other 
FDTs such as SDL, which have a static structure. An instance can dynami- 
cally create and terminate or release children instances and change their inter- 
communication structure. As an instance can be instantiated with alternative 
bodies, it is possible to change the entire sub-hierarchy of instances. 

The global behaviour of the system is characterized by the interaction of 
the executing modules, subject to the concurrency imposed on sibling modules 
by their parent module, and a priority principle that grants parent instances 
execution priority over its children. 

1.3 THE ESTELLE/GR 

The Estelle/GR separates the definition of system structure and behavior, as 
these two parts are syntactically unrelated. Three notations are used, including 
two alternative representations for a system structure: 

1. A structure tree diagram defines a static generic module hierarchy 
in a tree structure. It can define the dynamic structure of any general 
Estelle system. 

2. An instance block diagram defines the initial instance hierarchy and 
communication structure of an Estelle system which has a statically- 
determinable initial state. It is used to define Estelle systems limited a 
static structure, and uses a nested box notation similar to that of ASA-f 
and SDL. 

3. A transition tree defines a transition in the internal EFSM of a module 
body (or instance) of the specification structure. A series of transition 
trees defines a forest, which defines the full EFSM. The transition tree is 
represented using an SDL-like flow diagram notation. 
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The editor introduces a further informal simplified automaton notation 
which describes the internal behavior of a module in a simpler automaton form. 

A complete complete Estelle/GR specification consists of a single structure 
tree or instance block diagram, and a transition tree forest defining the 
internal behaviour of each module body or instance occurring in the structure 
diagram. 

In the following sections we define each of these syntaxes using the Trivial 
File Transfer Protocol to provide illustrative examples. The relative merits of 
the two structure notations are also discussed. We briefiy introduce the TFTP 
protocol used before continuing. 

1.3.1 The Trivial File Transfer Protocol 

The Trivial File Transfer Protocol (TFTP) is a simple protocol for reading 
and writing files across a network. It is defined in [Chi94]. Here we define 
a version of the TFTP in which the Reader and Writer are implemented as 
separate ‘request handlers’ within Initiator and Responder objects, and which 
are created when the User generates either a read (READ_RQST) or write 
(WRITEJIQST) request, and destroyed immediately on completion. We only 
describe and use examples of Writer behavior in this paper. 

A User acts as both the Client and a Server. The Client sends requests to 
the Initiator object, and the Server responds to requests from the Responder 
object. All network communication takes place between the Initiator and Re- 
sponder. Our implementation assumes an error-free network link, and connects 
the Initiator directly to the Responder. 

The Client initiates a connection by sending a write request ( WRITE_RQST) 
to the Initiator. If the Initiator is not busy with an existing transfer, it creates 
a Write Handler, and establishes a link between it and the Responder. The 
Write handler then forwards the write request to the Responder, which if it is 
not busy and the Server grants permission, creates a Write Handler to process 
the request. 

The Initiator and Responder Handlers communicate directly to exchange 
data. Synchronized acknowledgment and timeouts are ensure data integrity. 
The Initiator handler sends DATA packets, which the Responder handler ac- 
knowledges with ACK (acknowledgment) packets. Any errors result in discon- 
nection and the sending of an ERROR packet. 

On successful completion of the transfer, or receipt of an error packet, the 
handlers alert their parent Initiator or Responder objects, which destroy the 
connections and handlers. The Initiator also receives a result code from the 
Handler, which it returns to the User in a RESPONSE packet. 

1.4 STRUCTURAL REPRESENTATIONS 

The idea of representing a structured system of communicating components 
as a set of of nested boxes connected by vectors representing communication 
links is a familiar and useful one. Unfortunately, this notation assumes a static 
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system structure, thus it cannot be used to define a structural dynamic system, 
such as a general ISO Estelle system. 

In order to define a structurally dynamic system, we introduce a notation 
which we call the structure tree. This notation is not as informative as the 
nested box notation as it cannot make any assumptions about the dynamic 
instance and communication structure. However, as it is based on generic 
module definition, can fully define all structural aspects of an Estelle system. 

Which notation should be used depends on whether the system structure is 
dynamic or static. The nested box notation is more expressive than a structure 
tree, therefore it is recommended where the system is structurally static. At 
its most general, it can also usefully describe the initial structure of a dynamic 
system where this initial structure is statically determinable. 

1,4,1 Nested boxes notation 



TFTP (timescale seconds; default individual queue;) 




network_access_point 



Figure 1.1 The TFTP nested box diagram (showing the initial structure of the dynamic 
system) 



The nested box notation defines system instances which effectively have single, 
statically-determined module header and body parts. For this reason, it cannot 
define a dynamic system where headers have multiple associated bodies. 

The nested box notation thus defines not only the system structure, but also 
the module body initialization parts required to initialize that structure. 

Figure 1.1 shows the nested box representation of the TFTP structure. The 
nested box can describe the initial structure of this system, as it is statically- 
determinable. However, it is not definitive, as the full definition of the structure 
tree in Figure 1.3 reveals the definition of descendent modules for both the 
Initiator and Responder modules. 
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In Figure 1.1, each box defines a module instance and the graphical inclusion 
of one box within another indicates hierarchical substructuring. A box’s shape 
is used to define the mode of concurrency between the included child instances. 
The diagram shows three systemactivity modules executing asynchronously 
in parallel, as their parent instance (the specification) is unattributed. The 
Estelle/GR uses the box shapes shown in Figure 1.2 to define concurrency 
between children instances. 




process 

Child modules execute synchronously in parallel 



activity 

Child modules execute non-deterministically 



! unattributed 

I Child modules execute asynchronously in parallel 



A double outline is used to 
specify a systemprocess 
or systemactivity. 



Figure 1.2 Specifying concurrency between children modules in the Estelle/GR 



Child instance boxes should not be confused with channel declaration boxes, 
shown as a rectangle with a ‘folded’ corner ). These define channels for 

the containing instance. 

Communication links. A major feature of the nested box notation is the 
inclusion of communication link information. Channels and interaction point 
definitions are semantically grouped by a vector terminating at two “dots” . The 
extracted link attached between the User and Responder modules in Figure 
1.1 has the following characteristics: 



CLIENT 



U 



<user> 



user_access_point 



<provider> 

The solid defines an interaction point with an individual queue (a 

common queue is shown by a ‘(3)’)- vector label defines the channel 

shared by the interaction points, and the identifier in angled brackets defines 
the role of each interaction point. From these labels it is possible to look up 
what interactions each interaction point may send in the channel declaration. 
For instance, interaction point CLIENT may send interactions READ_RQST and 
WRITE JIQST. 



1.4.2 Structure tree notation 

A structure tree is a tree of generic modules. A generic module is itself visual- 
ized as a two level tree with the module header as root and associated bodies as 
children. The separation of module headers and bodies makes it possible specify 
multiple instance sub-hierarchies which the nested box notation cannot. 
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Figure 1.3 The TFTP structure tree 
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The tree is started using a special specification node and built downwards 
by adding generic modules as children of the module body in which they would 
be textually defined. As an example, the TFTP structure tree is illustrated in 
Figure 1.3. 

Generic module representation. A generic module is graphically defined 
as follows: 




The header definition part is named Header, and has bodies Body #1, Body #2, 
..., Body #n associated to it. A module instance can be created from the pairing 
of Header with any of the bodies during execution. 

A module body is always represented by a rounded rectangle, but a mod- 
ule header may be any of the nested box shapes listed in Figure 1.2, which 
determine the mode of concurrency between child modules. 

Communication links. The structure tree cannot represent communication 
links as it defines a structurally dynamic Estelle system, in which communica- 
tion links are only created during execution 

The structure tree is limited to defining the static communication inter- 
faces of module headers. These consist of interaction points, exported 
variables and parameters, and are shown as textual annotations of a module 
header node. 

This can be awkward in even a simple protocol such as TFTP, as is obvious 
in Figure 1.3. This is one reason the module instance diagram is recommended 
to be used whenever possible. 

1.5 BEHAVIORAL REPRESENTATION 

The Estelle/ GR uses a fiow diagram notation to define individual transitions 
in the extended finite state machine making up the internal behavior of a mod- 
ule instance. This notation has been widely popularised by SDL, is easy to 
understand, and describes all details of a transition definition. 

A flow diagram defining a transition in the Estelle/GR is called a transition 
tree^ and the set of transition trees making up an EFSM definition is called a 
forest. Figure 1.4 shows a small forest of transition trees. 

The basic structure of a transition tree is shown in Figure 1.5. The origin 
and destination states, the conditions necessary to fire the transition and the 
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Figure 1.4 A subset of the forest of transition trees which define the Writer Handler of 
the Initiator (Figure 1.12 shows the simplified automaton of this forest) 



actions taken on firing are explicitly shown as individual symbols in a fiow 
diagram. The different parts of a transition tree are described below. 

1.5.1 FROM and TO symbols 

The FROM and TO symbols may be included as condition clauses in the con- 
dition part of the transition definition to allow nesting on common origin and 
destination states (see the section on nested transitions below). All the tran- 
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From (origin) state 

Specifies the set of control states 
that the transition may fire from. 



Condition part 

The condition part defines a set of 
optional clauses, all of which must 
be fulfilled to enable the transition. 



Action part 

The action part defines an action 
executed by the transition. It may 
be named and contain local 
declarations. 



To (destination) state 

Specifies the control state entered after 
the transition has fired. 



Figure 1.5 The structure of an Estelle/GR transition tree 



sition examples in this section define the TO state as part of the condition 
part. 

1.5.2 Condition part 

The condition part is made up of optional condition symbols (listed in Fig- 
ure 1.6) each of which defines a condition which must be satisfied before the 
transition may fire. 

These conditions may occur in any order, but only once each. By treating 
the FROM symbol as a condition, it is possible to start the transition with any of 
the conditions listed in Figure 1.6. Combined with branched transition trees, 
this allows a number of transitions which respond to a common event to be 
semantically defined together (see the section on nested transitions below). 




48 




L5.3 Action part 

The action part is separated from the condition part by a solid box, which also 
indicates that the enclosed actions are atomically executed. Transition naming 
is handled by the labeling of this box. The action part also has a scope in which 
declarations can be made. This is done textually within a graphical declaration 

symbol ), which is included in the action part box. 

Unlike the condition part symbols, action symbols (listed in Figure 1.7), 
may be repeated. In the Estelle/GR we only define action symbols for Estelle- 
specific extensions to Pascal, and native Pascal statements are included in the 
graphical text symbol, . There are two exceptions to this rule: 

■ The Estelle exist-one expression has no graphical representation, as it 
is used as an operand in boolean expressions; 



A Pascal procedure call is shown explicitly, due to its value in abstract- 
ing detail. 




Figure 1.7 Esteiie/GR action symbols 
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Figure 1.8 A transition nested on a WHEN condition, showing the specification of error 
recovery in the Writer handler of the Initiator module of the TFTP. The enboldened 
FROM state indicates that the transition may fire from more than one state in the EFSM 



1.5.4 Nested transition trees 

The term transition tree is used as an Estelle transition may be split into 
branches within the condition part. A branched transition tree defines a nested 
transition, as informally defined in the Estelle ISO standard. Within a branched 
transition tree, the conditions above a split apply to each branch created by 
the split. 

The advantage of introducing branching into a transition tree is the ability 
to semantically group together transitions which result from a common event. 
For example, in the TFTP, error packets may be received at any time, in any 
state. Rooting a transition tree at a ‘WHEN ERROR’ condition, and branching 
the transition tree with different actions dependent on the current state, is 
a sensible way of specifying error-recovery behaviour. Figure 1.8 shows error 
recovery in the TFTP Writer Handler of the Initiator. The single transition 
defines three error-handling procedures depending on the state the machine is 
in, in a single transition tree definition. This is semantically more meaningful 
than defining three procedures in separate, not obviously related transitions. 

1.5.5 The initialize transition 

The initialize part of a module behaviour part is represented as a transition 
tree starting by a special initialize symbol, The initialize transition 

for the TFTP specification module is shown in Figure 1.9. This initializes the 
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User, Initiator and Responder instances at the system level, and establishes 
the link between the Initiator and Responder. 

Note that this initialization is statically determinable (there is only one 
configuration possible from the initialize transition), which is why the initial 
structure of the TFTP protocol can be described by an instance block dia- 
gram: the instance block diagram effectively interprets this initialization part 
However, when used to define a system, the instance block diagram implicitly 
defines this initialization part. 




transi 



initiator WITH 
InitiatorBody 



Responder WITH 
ResponderSody 



User WITH 
UserBody 

I 

CONNECT Initiator.N 
TO Responder.N 



Figure 1.9 Initialize transition for the TFTP specification module 



1.5.6 Special considerations 

Estelle FORONE and ALL statements are represented as complex statements of 
other Estelle/GR symbols. Figure 1.10 show the templates for these constructs. 



forone <DOMAIN> 



( <CONDITION> ) 



statement 
block to 
execute on 



TRUE 



statement 
block to 
execute 
otherwise 



(a) 



all <DOMAIN> ** — i 



statement 
block to 
loop 
through 



(b) 



Figure 1.10 Estelle/GR complex statements: (a)f orone and (b)all 
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The ANY macro is represented in a transition tree using a special symbol, 
j \^. It defines identifiers which are available to all symbols following it in 
the transition tree. 

1.6 THE PROTOTYPE EDITOR 

The prototype editor has two main functions: 

■ It is a syntax-directed editor for the definition of a specification using the 
Estelle/GR syntax. 

■ It translates a graphical Estelle/GR document into Estelle/PR code. 

These two functions combined enable the editor to turn the Estelle/GR into 
a powerful graphical technique that can make use of existing tools supporting 
the Estelle/PR technique. 

The editor also provides a navigational aid for complex module body defini- 
tions in the form of a simplified automaton view. 

1.6.1 Editor structure 

The editor provides separate interfaces for the definition of system structure 
and module behaviors. 

Launching the editor opens the structure editor. The structure editor opens 
a single specification at a time, and controls the usual functions of file handling 
and printing, as well as the import and export of Estelle/PR specification 
documents. The structure editor is used to define a specification structure in 
the general structure tree syntax of the Estelle/GR. The instance block notation 
is not supported. 

For each module body of the structure tree defined, a behavior editor can 
be opened in which the behavior of that module body is defined using the 
Estelle/GR transition tree syntax. Multiple behavior windows can be open si- 
multaneously, making concurrent development of bodies possible, and enabling 
‘cut, copy and paste’ editing between two bodies. The structure tree in the per- 
manently open structure editor is a useful navigational aid for moving between 
a number of module body definitions. 

The structure and behavior editors are very similar in presentation, and a 
screenshot of the behavior editor is presented in Figure 1.11. 

1.6.2 Simplified automaton view 

The behavior editor can display a simplified automaton view of its behavior 
definition in a separate window. Figure 1.12 presents the simplified automaton 
view of the set of transition trees defined in Figure 1.4. 

The automaton is simplified as it does not display any transition information, 
and aggregates all transitions between two states into a single macro- transition^ 
as defined in the work of GROPE [NP93, NP90]. The simplified EFSM therefore 
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symhcils 



nthMsBi 



Conlttfoii pin 



symbols- 



Sk30ittnt 

ClIWll 



f((tdow 



Screenshot of the behavior editor window 



consists of all states, but with at most one arc in each direction between each 
state pair, labeled with the names of the individual transitions aggregated on 
that arc. 

The utility of the simplified automaton view is derived from the linking of 
each transition names in this view with its full transition tree definition in the 
behavior editor: When the transition name is selected in the automaton view, 
the transition definition is centered and highlighted in the behavior editor. 

A module behavior definition may stretch over several virtual screens, whereas 
the simplified automaton will usually fit on one. This makes the latter a use- 
ful navigational aid when defining or exploring a module body behavior. In its 
simplified form it provides an overview of the transition definitions, and by way 
of the dynamic links, functions as an ‘index’ into the module body definition. 



1.6.3 Ongoing work 

The editor currently cannot import Estelle/PR specification documents. The 
instance block notation for specifying structurally static systems is not sup- 
ported. These features are under development. 

The editor will ultimately be integrated into the XEdt toolkit, making seam- 
less use of the graphical technique and its set of Estelle/PR-based tools possible. 
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Figure 1.12 The simplified automaton view of the transition tree definitions in Figure 1.4 
(Displayed sideways for easier comparison) 



1.7 CONCLUSION 

The recently completed MIL-STD-188-220A [FAS"*"97] Estelle specification is 
one of first Estelle descriptions to be included as an official part of a commercial 
formal specification. To encourage further acceptance of the Estelle technique, 
we believe that it is essential to make it accessible to a wider range of non- 
technical users. We believe that a graphical syntax and support tool is an 
important contribution to this process. 

In the process of developing a graphical representation for Estelle, we found 
that it is more complex than similar techniques like SDL, as it permits a system 
to dynamically change its structure. This structural dynamicity means that 
the common “nested box” structural representation is not expressive enough 
to define an Estelle system, and a less expressive but more general structure 
tree notation had to be introduced. We retain the “nested box” notation in the 
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Estelle/GR though, for use the large subset of Estelle specifications which do 
not have a dynamic structure and for which it is definitive. 

We believe that we have created a graphical syntajc which will be immediately 
familiar to existing Estelle users, being built on the knowledge of existing Estelle 
and other FDT notations. 

The functionality of the editor, and integration with existing Estelle/PR 
should also make the graphical technique a powerful and practically useful 
tool. 
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Abstract: Feature interaction is one of the most intriguing problems in re- 

search and development of telecommunications systems. Features may interact 
and result in undesirable system behavior. Today the analysis of interactions is 
conducted in an ad hoc manner by subject matter experts. This leads to time- 
consuming feature design and testing without any interaction-free guarantee. 

We present a formal approach for the detection of feature interactions dur- 
ing feature design, specification, implementation, and integration. We use au- 
tomata to model switch behaviors and services rendered to users. Given a 
protocol system specification, we propose detection algorithms and prove their 
correctness and optimality; they require minimal checking to conclude whether 
a given system is interaction-free. To aid with the introduction of new features 
to an existing protocol system, we describe efficient algorithms for the incremen- 
tal validation of interaction-free conditions. Moreover, given a set of design and 
integration requirements, we obtain necessary and sufficient conditions to prove 
that an interaction-free system can be built based on the given requirements. 

We illustrate various concepts and techniques using telephony examples. 

1 INTRODUCTION 

Feature interaction is a major roadblock to the development and evolution of 
telecommunications systems. Typical telecommunication switches in a system 
support hundreds of features [1], combinations of which are marketed as ser- 
vices. Though some feature interactions are desirable by design, others could 
arise unexpectedly, resulting in user annoyance or adverse system operation. 
Given a complex switching system implementation, it is formidable to check 
for feature interactions. Hence, much effort is devoted during feature design and 
integration phases to ensure that unintented feature interactions do not exist. 
Currently subject matter experts conduct such analysis in an ad hoc manner. 
The task has been difficult due to large number of features on a system and 
complicated interaction scenarios among them. This leads to time-consuming 
feature design and testing, yet lack of interaction-free guarantee. 
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The analysis of feature interactions is a matter of determining if users’ expec- 
tation of feature behaviors is consistent with that exhibited by a system. Since 
various combinations of features can be simultaneously in use, an interaction- 
free system means that the behavior of a feature or feature set must be inde- 
pendent of the presence or absence of any other features. Two questions follow 
in investigating feature interactions: (i) Given a design specification of a system 
that offers many features, is the system design interaction-free? (ii) Given a 
set of feature requirements based on users’ expectations, is it possible to design 
an interaction-free system that meets those requirements? 

To validate in an effective manner that a system is interaction-free, a major 
challenge is to minimize the number of feature sets to be analyzed. Similarly, in 
adding a new feature sets to an existing interaction-free system, the challenge is 
to avoid analyzing those subsets of features of which the interaction-free status 
has not changed. 

Approaches to solving the feature-interaction problem has proliferated over 
the past several years [2, 3, 4]. Many of these efforts apply formal techniques, 
which range from languages for describing composition and alternation of fea- 
tures [15], to state transitions or process algebra based modeling in conjunction 
with detection techniques such as reachability analysis or model checking (e.g., 
see [5, 6, 12, 14]). Nevertheless, they mainly focus on detection mechanisms; 
the complexity of the above mentioned challenges remains an open issue. 

This paper addresses the challenges in the context of the two raised ques- 
tions. We present a formal approach to specify features from both user and 
network perspectives, and define conditions that guarantee a system to be free 
from undesirable feature interactions. Regarding the first question, we study 
efficient algorithms for feature interaction detection. We derive a necessary and 
sufficient set of combinations that need to be tested, and show that there is no 
need to check every possible combination of features. Furthermore, we prove 
that our algorithm is optimal in a sense that the number of tests conducted 
is minimal. Depending on how feature sets are grouped, this can significantly 
reduce the number of tests performed. Concerning the second question, we 
derive necessary and sufficient conditions for the design of an interaction-free 
system that satisfies feature requirements. We present an efficient algorithm 
and show that it is optimal. In an evolving telecommunications system, the 
system is augmented with new features, and the new features may interact with 
each other or with existing features. We thus study conditions for interactions 
due to introducing new features and discuss algorithms for their testing. 

The remainder of the paper is organized as follows. In the next section we 
introduce the framework and present the basic definitions of protocol systems, 
features and their interaction. In Section 3 we address the issues in validating an 
interaction-free system. In Section 4 we illustrate our methods on a telephony 
example. In Section 5 we discuss the design and integration of interaction-free 
systems. Section 6 deals with evolving systems, followed by our concluding 
remarks in Section 7. Due to the space limit, we omit all the proofs and 
intermediate results and refer the readers to [10]. 
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( Party, )^-i ► 




; User ; ; 


Switch 


(Party„)-*-: ► 





Figure 1 A reference model of a protocol system 



2 PROTOCOL SYSTEMS 

A communication system provides a set F of services^ or features to its users. 
The feature set F includes the basic feature Fq and a set of value-added features 
Fi^ i = 1, 2, •••, A'. Communication between the system and the users 
takes place via two sets of matching service primitives: 5p = {/i, / 2 j * * *} 
and 5 f = {/i, / 2 , • * *}• The sets 5p and 5p represent service primitives from 
the user’s point of view and the system’s (e.g., switch’s or network’s) point 
of view, respectively. Each feature Fi has two associated subsets of matching 
service primitives 5p. C 5p and C 5p with the property that a primitive 
/ is in Spi if and only if its matching primitive / is in 5^^. We assume that 
5p = Ui5p. and 5p = Ui5p. . The switch may have additional non-service 
primitives which are used to communicate with other network entities. 

We assume that for each element / in 5p there is one and only one match- 
ing element in 5p and vice versa. The matching relation between the service 
primitives is for the corresponding send and receive events, denoted by \x and 
lx respectively, for a message x between a user and the switch in synchronous 
communication [7]. The matching relation can be extended from the service 
primitives to strings and languages over them. Two strings fp\ fp2 ’ ' ‘ fpk ^ 
and /?: /^2 ■ ■ * fqk ^ 'i^o.tch if /p. and /^. match for i = 1, • • • , A:. For a string 
X over 5p or a§f, we denote by mMch{x) the string that matches x. For a 
language L over the alphabet 5p or 5p, let match{L) = {match{x) : x E L]. 
Note that since the matching relation among the service primitives is one-to- 
one and onto, if x' = match{x) then also x = match[x')^ and, consequently, if 
L' = match(L), then also L = match{L'). 

Based on the network design and user demands, each user is able to use a 
subset of features in F, including at least the basic feature Fq. Let T = {F : 
Fo G F C F} be a class of all the possible feature sets offered by the system 
(this need not be the complete powerset) for a group of communicating parties; 
all sets include the basic feature Fq. Figure 1 depicts the relationship between 
network and users. In our general framework, the term “user” means a group of 
communicating parties (shown as a dash box in Figure 1); the features set of a 
user therefore refers to the combinations of features used by all communicating 
parties. We also discuss a special setting in which a feature set is the set of 
features available to each communicating party. 

We model the behavior of each feature set F by a user automaton Ap with 
input symbols Sp. We model the switch behavior by a switch automaton A 
whose input symbols consists of the service primitives of all the features Sp 
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and possibly other non-service primitives. The automata have an initial “idle” 
state. All the states of the user and switch automata are considered accepting. 
We use L{A) to denote the language accepted by an automaton A; in the case 
of the switch automaton, the transitions on non-service primitives are treated 
as T moves, i.e., L{A) is a language over the alphabet 5p. 

Definition 1 A protocol system P on feature sets class P contains a switch 
automaton A and a set of user automata {Ap ■ F € P} (one for each feature 
set F in P) which communicate with A by matching service primitives.^ □ 

In order to identify each transition in the switch automaton on a per feature 
basis, we also tag each transition with the corresponding feature(s) of which 
the execution traverses the transition. Multiple features may share a transition, 
i.e., the execution of these features may traverse the same transition labeled 
with either a shared primitive or a non-service primitive. In this case the 
transition is tagged by all the features that share the transition. A transition 
in the switch automaton is F^-related if it is tagged with Fi. A transition in 
the switch automaton is F-related if it is F^-related for some Fi G F. Note that 
the feature tags are not part of the alphabet for the switch automaton. 

Consider the switch behavior with respect to a feature set F in P. If no other 
features are present, then the switch will traverse only F-related transitions; 
that is, the other transitions are as if they are missing. This gives rise to the 
following definition of a restriction operator. 

Definition 2 Let A be an automaton whose transitions are tagged by the 
features. The restriction of A on a set of features F, denoted pp{A)^ is the 
automaton obtained from A by deleting all transitions that are not F-related. 
The remaining transitions retain in their tags only the features from F. □ 

To the parties that jointly use feature set F, the user automaton Ap should be 
consistent with the view pp{A) supported by the switch. Formally, 

Definition 3 A protocol system P = (A, {Ap}p) on feature set class P is 
consistent if L{Ap) = match{L{pp{A))) for all F e P, □ 

Note that both the switch and user automata can be nondeterministic. There 
are various notions of equivalence for nondeterministic automata, including 
language (trace) equivalence, observational equivalence etc. [13]. In this paper 
we will use language equivalence, mainly for reasons of simplicity; a similar 
development can be carried out using other equivalences. 

Since the matching of service primitives of the user and switch automata is 
unique, given the switch automaton of a consistent protocol system, the user 
automata are well defined and unique in terms of language acceptance. 

Example 1 Figure 2 shows a switch automaton and a user automaton as part 
of a protocol system from telephony. We label transitions in a format [!,?]X«Y, 



^For clarity we omit specification P of the underlining protocol system if there are no 
ambiguities. 
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Figure 2 An example of (a) a switch automaton and (b) a user automaton 

where X corresponds to a feature tag, and Y is a primitive. The labels pre- 
ceded with either or “?” are service primitives, and the ones without are 
non-service primitives. The switch is for calls involving two parties, the caller 
and the callee. Correspondingly, the basic feature set has two components: the 
originating POTS (Plain Old Telephone System), denoted O in the figure, and 
the terminating POTS, denoted T. The switch provides three valued-added fea- 
tures: Originating Call Screening (OCS), Automatic CallBack (ACB), and Call 
Forwarding (CF). The user automaton represents expected caller behaviors. □ 

Assume a set of operative features that includes a feature set F and possibly 
an additional set E. Consider the switch behavior as perceived by an observer 
who tracks only the communications involving F. We can classify transitions 
of the switch automaton into three categories: F-related transitions; E'-related 
but not F-related transitions; and the rest (neither F- nor F-related) transi- 
tions. The switch now traverses transitions in the first and second categories 
but not the ones in the third category, as if features in F - (FUF) are not avail- 
able. Consequently, we can delete the transitions in the third category from 
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the switch automaton without affecting the apparent behavior of the switch. 
Furthermore, the associated semantics of transitions in the second category are 
irrelevant to F; hence from F’s point of view we can change these transitions 
to r moves. This gives rise to the following projection operator. 

Definition 4 Let A be an automaton whose transitions are tagged by the 
features. The projection of A on a set of features F, denoted 7 Tf(A), is the 
automaton obtained from A by changing to r moves all transitions that are not 
F-related (the r transitions retain their tags). 

For a pair of feature sets F and F, the projection of the automaton A on 
F w.r.t. (or, in the context of) F, denoted by 'Kf\e{A)^ is the automaton 
^f(pfuje;(A)), i.e., it is the automaton obtained from A by changing the tran- 
sitions as follows: (i) All F-related transitions remain unchanged; (ii) All tran- 
sitions that are F- but not F-related become r moves; and (iii) All the other 
transitions (those are not (F U F)-related) are deleted. □ 

The restriction operator pp corresponds to the situation where only feature set 
F is available. The projection operator ttf corresponds to the situation where 
one is observing the system behavior only from F’s viewpoint, though other 
features may be available and active. The operator 7Tf\e combines the two 
cases. 

The restriction operator pf is similar to that of protocol pruning [11] where 
the transitions labeled with service primitives not in the feature set F are 
deleted. Furthermore, only the strongly connected component with the initial 
state is maintained for the protocol operations. The projection operator is 
different from protocol projection [9], which is intended for protocols with several 
distinguishable services. The goal there is to construct image protocols for each 
service that preserve safety and progress properties. In [11] the projection is 
done by aggregating states into blocks (and message values into blocks). 

We also define our restriction and projection operators in languages. 

Definition 5 Given a string x € 5p (x G 5p) and a subset of features F G 
F, the projection of x (x) onto F, denoted by 7Tf{x) (7Tf(^)), is obtained by 
deleting all the symbols in x (x) that are not in Sf {Sf)- The definition can 
be extended to languages in a straightforward way: 7Tf{L) = {7Tf{x) : x G L}. 
The restriction of L on F, denoted pf{L)^ is the set of all strings of L that 
contain only symbols in 5 f (or in Sf for a language on the user side). The 
projection of L on F w.r.t. F is 7Tf\e{L>) = '7Tf(pfuJ5;(T)). □ 

Example 2 Figure 3 depicts the projection tt[o}\{t}{A) of the switch automa- 
ton in Figure 2(a). It is the basic POTS as seen from the caller. For simplicity 
we have removed r transitions and redundant states. □ 

We now define interactions between feature sets. The definitions of independent 
feature sets and interaction-free protocol systems follow. 

Definition 6 A feature set F G F is independent of (or free of interactions 
from) another feature set F, denoted as md(F,F), if L(7 Tf|f(^)) = T(pf(A)). 
Otherwise, we say that F has interactions from F. □ 
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Figure 3 The projection 7 T{o}|{t}(^) of the switch automaton in Figure 2(a) 



Note that this relation is not symmetric; ind{F, E) does not imply that ind{E^ F). 
Moreover, interactions between E and F need not concern us unless (F U E) 
belongs to some feature set offered by the protocol system. 

Definition 7 A feature set F G F is independent (or interaction-free) in T 
if ind{F, E) holds VF such that (F U F) C F for some H e F. A protocol 
system P with feature set class F is interaction-free if every set F 6 F is 
interaction-free in F. □ 

For a protocol system F, the design and engineering of the system is on the 
switch automaton A. On the other hand, the services provided from the user’s 
point of view are specified by the user automata. Hence, analyzing feature 
interactions means validating that P is consistent and interaction-free. In the 
next section we investigate the detection of feature interactions. 

3 FEATURE INTERACTION DETECTION 

Consider a protocol system P = {A,{Af}t) on a class F of feature sets. 
Checking for the consistency of P is straightforward from the definition: we 
need to check for each feature set F G F that L{Af) = match{L{pF{A))) . The 
interesting part is checking for interactions. 

The straightforward way to check for interaction-free is to check ind(F, F) 
for every pair of feature sets, F, F with (F U F) G F. We seek ways to avoid 
checking all possible pairs. As for the betsic operation of checking interactions 
of some pairs of feature sets, from Definition 6, the computation is reduced to 
checking equivalence of two automata, which has been well studied in automata 
theory [8]. In general, it is an expensive operation and we want to minimize 
the number of such operations in feature interaction detection process. For 
convenience, we assume that each such operation has a unit cost, and we want 
to design feature interaction detection algorithms that minimize the total cost. 

Intuitively, if there are no interactions from a feature set then there are no 
interactions from its subsets as well. 

Lemma 1 Suppose that F, F, F' are sets of features with F' C F. If md(F, F) 
then also md(F, F'). The independence relation ind is transitive on compara- 
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ble sets: for feature sets F C K C L, if ind{F^ K) and ind{K, L) then also 
ind{F,L). □ 

We proceed now to study how to check whether a given protocol is interaction- 
free. We first consider a protocol with two parties, the originating and the 
terminating party. The same development can be extended along the same lines 
to the case of multiple parties. Assume we are given a switch automaton A, 
and that the features are partitioned into originating and terminating features, 
there is a class Fo of originating feature sets and a class Fr of terminating 
feature sets. A feature set in Fo can pair with a feature set in Fr, and vice 
versa. There is a basic originating feature set Fq included in all the sets of 
Fo, and a basic terminating feature set Eq included in all the terminating 
feature sets. We wish to determine whether there are any feature interaction 
between the two parties, i.e. whether the observed behavior by one party for 
some feature set depends on the feature set of the other party. 

Formally, a feature set F G Fo is independent of a feature set E G Fr, 
denoted ind{F^E), if 7Tf^e{A) = TrF^Eoi^)^ i-C-, the originating side cannot 
tell the difference between the terminating side using E or its basic feature 
set Eo (note that it has to use at least Eq). Similarly, E is independent of 
F if nE\F{A) = 7TE\Foi^)- An originating or terminating feature set is called 
externally independent if it is independent of every feature set of the other 
party. (Note that it may still have interactions from features of the same side). 
The protocol system is externally independent if all the feature sets are. 

The definition of external independence asks to check two language equalities 
for each pair of feature sets F, E with F G Fo and E G Fr> We will use the 
properties from the last subsection to reduce this number. 

Definition 8 The maximal subclass of a class of feature sets F, denoted by 
F*, is a subset of F such that (i) No feature set in F* is a proper subset of 
any other one in F\ and (ii) For each feature set G G F there is a feature set 
F e F* such that G C F. □ 

For a given class of feature sets F, there is a unique maximal subclass F*; it 
consists of the set-theoretically maximal sets of F. It can be easily obtained by 
eliminating all the elements in F that is a proper subset of another element. 
Therefore, for the two disjoint feature set classes for the two parties, Fo and 
Ft, we have the two maximal subclasses, Fo* and Fr*- The feature interac- 
tion procedure is summarized in Algorithm 1. Line 2 and 5 call a subroutine 
md(', •), which checks for independence of two feature sets, as in Definition 6. 
It constructs two automata from the two given feature sets and checks whether 
they are equivalent or accept the same language with a unit cost. 

The following two theorems show the correctness of Algorithm 1, i.e., check- 
ing for interaction-free with respect to the maximal feature sets is sufficient. 

Theorem 1 A feature set F G Fo is externally independent if and only if 
VE G Fr* ,ind{F,E), i.e., F is independent of every maximal feature set E of 
Ft- Similarly, A feature set H G Ft is externally independent if and only if 
\/GeFo*,ind{H,G). □ 
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Algorithm 1 (Feature Interaction Detection - Two Parties) 

Input: Feature sets To , To* ^ Tr* • 

1 for (each pair {F G To^ E G Tj-*)) do 

2 if {ind{F,E) = FALSE) 

3 return “feature interaction detected” ; 

4 for (each pair {H G Tr, G G To*)) do 

5 if {ind{H,G) = FALSE) 

6 return “feature interaction detected”; 

7 return “feature interaction free” ; 



Thus, for each F G To {H € Tr) the cardinality of Tr* {To*) determines 
the number of feature sets that we must validate against in order to claim 
that F (H) is independent in T. In the worst case, it is the total number of 
value-added features in To {Tr)] in other words, every feature set in To {Tr) 
consists of exactly one value-added feature and the basic feature. In the best 
case, the cardinality of To {Er) is one, that is, there is a feature set in To 
{Tr) that contains every originating (terminating) value-added features. 

From Algorithm 1, the pairs of feature sets to be checked for independence is 
\Eo\ X |7V*| + |7V| X \To*\ whereas a brute-force checking requires 2\To\ x \TrY 

Corollary 1 Given a class of feature set T. Let n and m be the cardinality 
of To* nnd Tr*, and N and M be the cardinality of To and Tr, respectively. 
To check that every feature set is externally independent. Algorithm 1 reduces 
the number of tests from 2NM to nM -f Nm. □ 

Can we further reduce the number of tests for external independence? The 
following theorem shows that Algorithm 1 is optimal in a sense that it conducts 
all the necessary checking and, therefore, there is no guarantee of external 
independence if less tests are performed. 

Theorem 2 Let 5 be a set of pairs {F,E) with F G To, E G Tr- If S does 
not contain {To x Tr*) U {To* x Tr), then there is a protocol system P such 
that \f{F,E) G S', ind{F,E) holds, but P is not externally independent. □ 

An important special case is that there is a feature set that includes all the 
features: JF = Ft and G = Fq- In this case, m = n = 1, and we only need to 
perform a linear number of tests: 

Corollary 2 Suppose that there exists a feature set E G Tr and G G To that 
include all the features, i.e., E = Ft and G = Fq. Then all the feature sets 
are externally independent if ind{F, E) for all F G To and ind{H^ G) for all 
H G Tt’ The number of tests is thus reduced to M + where and N and M 
be the cardinality of To and Tr, respectively. □ 

We come back now to the general framework. We have a communication pro- 
tocol P, given by the switch automaton A, with a class T of feature sets. We 
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Algorithm 2 (Feature Interaction Detection - General Case) 

Input: Feature sets T 

1 for (each F e T) do 

2 construct interaction graph Dp] 

3 for (each weakly connected component of Dp) do 

4 find a sink node G; 

5 i{ {ind{F,G) = FALSE) 

6 return “feature interaction detected” ; 

7 return “feature interaction free” ; 



wish to check if P is interaction-free, without checking all the pairs of feature 
sets of F, 

First note that Lemma 1 implies that we need only perform independence 
tests ind(F^E), where JS is a maximal set of T. For, if E is a proper subset 
of another set G of then we can test instead ind{F,G); if it holds, then 
also ind{F,E). Recall also that independence of a feature set F requires that 
ind{F, E) for all sets E such that E U E is contained in some feature set G 
of F. Thus, we only need to test pairs (E, G) of feature sets of F such that 
F C G and G is a maximal set of F. Do we need to test all these pairs? Not 
necessarily. We investigate below the pairs that need to be checked. Although 
the choice of these pairs is not necessarily unique in this case as we shall see, 
the number of pairs is uniquely determined. 

Consider the partial order induced by set containment on the class F of 
feature sets. That is, we form a directed graph D with the feature sets as 
nodes and with an arc E ->* G if E C G. By ‘connectivity’ below we mean 
weak connectivity, i.e., the directions of the arcs are ignored and the graph is 
treated as undirected. 

For a node (feature set) E, let be the interaction graph, a subgraph 
induced by all the proper descendants of E, i.e. all nodes corresponding to sets 
that properly contain E. Let cp he the number of connected components of 
Dp. We shall show that necessary and sufficient to verify 

that the protocol is interaction-free. 

For each feature set F £ F and each connected component of Ef, we select a 
sink of the component G (i.e., G is in the component and is a maximal set of F) 
to form a pair (E, G). Let 5 be a set of all such pairs. Note that a component 
may have several sinks so there is a choice for which one we pick for G to test 
against E. That is, 5 is not uniquely determined, although its cardinality is 
determined, namely Yip ^f- The procedure is summarized in Algorithm 2 and 
following theorem proves its correctness: 

Theorem 3 If ind{F, E) for all pairs in 5, then P is interaction-free. □ 

We can show again that Algorithm 2 is optimal if we access the switch 
automaton through independence tests; if we omit any of the tests in Algorithm 
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2 then there is no guarantee of interaction-fee. We can assume without loss of 
generality that we test pairs (F, E) with F C E feature sets of F. 

Theorem 4 Let i? be a set of pairs of sets of features. Suppose that there is a 
feature set F G F and a connected component C of Dp such that R does not 
contain any pair (F, E) with E in the connected component C. Then there is a 
protocol system P that passes all the independence tests in R but the protocol 
is not interaction-free. □ 

An important special case is that there is a feature set that includes all the 
features: F = F, and it is the sink node of all connected components of the 
interaction graphs of all feature sets. We only need to check each feature set F 
against E: K 

Corollary 3 Suppose that there exists a feature set F G F that include all the 
features, i.e., F = F. Then all the feature sets are independent if ind{F, E) for 
all F G F. The number of tests is thus reduced to N where N is the cardinality 
ofF. □ 

4 EXAMPLE 

Consider the switch automaton A given in Figure 2 and assume that a caller can 
use any combination of the two originating features, OCS and ACB, whereas 
a callee has the choice of using the terminating feature CF. The feature set 
class F in the setting of Section 3 is F = {{0, OCS, ACB}, {0, OCS}, {0, 
ACB}, {T, CF}}. The following illustrates how a pair of feature sets can fail 
the independence checking. 

Assume that a user a has the feature set {O, OCS, ACB} and another user 
b has the feature set {T,CF}. Assume further that a has c on the screening 
list for OCS, and b has c as the forwarding number for CF. Figure 4(a) and 
(b) depict the projections -n{o,ocs,ACB}\{T,CF}{A) and tt{o,ocs,acb}\{t}{A) 
respectively of the switch automaton in Figure 2(a). The two automata accept 
the same set of language except that the automaton in (a) also accepts a string 
. . . O-Connect(c). . .through states S9 and SIO but the automaton in (b) does 
not. The string corresponds to the case that user a attempts to call b, who in 
turn forwards the call to c; hence a is connected to c even though c is on a’s 
screening list. 

Based on our results in Section 3, Table 1(a) summarizes the independence 
checks we need to perform before claiming that the feature set is externally 
interaction-free. In addition, we need to check that OCS and ACB are inde- 
pendent of each other. That is, we need to check for L{7T[o,ocs}\{acb,t}{^)) = 

L{'^{o,ocs}\{t}{A)) as wellasL(7r{o,y4CB}|{oc5,T}(^)) = L{'^{o,acb}\{t}{^))‘ 

According to the general framework in Section 3.3, on the other hand, the con- 
text for each independence check will be different. Note that in this setting 
the feature set class F ={{OCS, 0, T}, {ACB, 0, T}, [OCS, ACB, 0, T}, 
{0, CF, T}, [OCS, 0, CF, T}, {ACB, 0, CF, T}, {OCS, ACB, 0, CF, T}}. 
Table 1(b) lists the six checks we derived from the interaction graph depicted 
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Figure 4 Projections (a) Tt{o,ocs,ACB}\{T,CF}{A) and (b) F{o,ocs,acb}\{t}{A) 
of the switch automaton in Figure 2(a) 





(a) 




(b) 
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ind({0,OCS,ACB}, {T,CF}) | 


l_^ 


ind({OCS,ACB,0,T}, {OCS,ACB,0,CF,T}) 


2 


ind({0,0CS}, {T,CF}) | 


1 2 


ind({OCS,0,T}, {OCS,ACB,0,CF,T}) 


3 


ind({0,ACB}, {T,CF}) | 




ind({ACB,0,T}, {OCS,ACB,0,CF,T}) 


1 4 i 


1 ind({T,CF}, {0,0CS,ACB}) | 




ind({0,CF,T}, {0CS,ACB,0,CF,T}) 






1 5 


ind({OCS,0,CF,T}, {OCS,ACB,0,CF,T}) 






1 6 


ind({ACB,0,CF,T}, {OCS,ACB,0,CF,T}) 



Table 1 A summary of independence checks 



in Figure 5. There is a one-to-one correspondence in the semantics of these two 
sets of checks. 
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{OCS, 0,T} 



{ACB, 0,T} 



(O, CF, T} 




Figure 5 The interaction graph for our example 

5 DESIGN AND INTEGRATION OF INTERACTION-FREE 
PROTOCOL SYSTEMS 

In the previous development we have assumed that given a switch automaton 
and the user automata for the various subsets of features what the users will 
actually see in their interactions with the switch: this is basically what the 
consistency condition says - the language of a user automaton can be derived 
from that of the switch automaton. On the other hand, when new features are 
created, specifications for the features are first created before the features get 
incorporated in the switch. It is desirable to analyze feature interactions at this 
stage of design, and indeed typically during the generation of requirements for 
new features, system engineers analyze and list interactions with other features. 
In this point of view, we consider user automata (or languages) for various 
subsets of features to be specifications of what the users are supposed to see for 
different feature sets - i.e. what is desired. We wish to analyze the interactions 
of the features on the basis of these specifications. 

A similar situation arises if we have different systems that need to be inte- 
grated. In this case the automata for different features represent the user views 
for different protocols that were constructed separately and we need to deter- 
mine whether it is possible to combine them in a consistent manner without 
interactions. 

We first describe a specification system that is typically constructed from 
design requirements. We want to check whether it is possible to build a pro- 
tocol system, an implementation from the specification, that meets the design 
requirements and is interaction-free. 

Definition 9 A specification system C for a set of features F = {Fj : i = 
0, is a finite set of user automata {Ap : Fq E F C F}, where each 

automaton Ap has input alphabet Sp. The family Tq of feature sets for which 
an automaton is specified may or may not be the complete power set of F = 
{Fi : z = 0, • • • , r} of all subsets that include the basic feature Fq. ^ □ 

Definition 10 Let C = {Ap : F G Fc} be a specification system over a 
set of features F = {Fi : i = 0, The system C is interaction-free if 

there is a consistent, interaction-free protocol P = {A^[Ap : F G Fc}) whose 
user automata are as specified by the system C; we say that the protocol P 
implements C = [Ap : F G Fc}. O 



^This corresponds to the case that features can be obtained only in certain combinations. 
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Although we did our analysis before based on the switch automaton, we can 
carry out a similar analysis equally well based on the user automata. That is, 
we can extend our methodology and algorithms to apply in the setting as well. 

Theorem 5 A specification system C = {Ap F e Tc} is interaction-free if 
and only if L{Ap) = ttf{L{Ae)) Q L{Ae) for all feature sets F C E of Fc- □ 

We can show along the same lines as Theorem 3 that it is sufficient to 
verify the equality L{Ap) = 7Tf{L{Ae)) only for the pairs (F, E) of the set S of 
Theorem 3; the equality then is implied for all other pairs F C E. Furthermore, 
clearly the containment L{Ap) Q L{Ae) needs to be checked only for the pairs 
(F, E) in the Hasse diagram (transitive reduction) of the partial order that is 
induced by the feature sets in F, i.e., for the pairs F C F in F such that there 
is no G E F with F C G C E. 

6 INCREMENTAL VALIDATION 

Suppose that we have a consistent, interaction-free protocol system P with 
switch automaton A and user automata Ap, F E F, There are two possible 
ways of extending P: adding new features, i.e., modifying the switch automaton 
A; or adding new feature sets to F only. In the following we discuss a general 
scenario of adding both a new feature and new feature sets. 

Consider the introduction of a new feature F/v+i to protocol system F. It 
results in a new protocol system Q, where Q consists of: (i) A new switch 
automaton B\ (ii) A new class of feature sets ^ = F U {Gi : F/v+i G G^}; ^ 
(iii) A user automaton Aoi for each new feature set Gi; and (iv) The old user 
automaton Ap for every old feature set F e F. We would like the new protocol 
to provide the same service for each one of the old features, hence the condition 
that the user automata for the old features remain the same in Q. To verify 
that Q is consistent, we need to check again for every old and new feature F 
that L{Ap) = match{L{pp{B)). Note that we have to verify again consistency 
for the old features since the switch automaton has changed to an arbitrary 
new automaton B. 

For feature interaction detection, we do not need to check from scratch; we 
can use the fact that the old protocol was interaction-free to avoid checking the 
old features. The procedure is summarized in Algorithm 3. 

Theorem 6 Suppose that a consistent and interaction-free protocol system P 
of feature set F is incremented with new feature sets F C Q, resulting in a new 
consistent protocol system Q. Algorithm 3 determines correctly whether the 
incremented protocol system Q is interaction-free. □ 



^We assume that all feature sets in ^ remain in Q. Adding the new feature Fjv+i results in 
adding a new set of feature sets, each of which contains Fjv+i- 
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Algorithm 3 (Feature Interaction Detection - Incremental Validation) 

Input: Two feature sets classes T (old) and Q (incremented); 

^ is the set of new feature sets. 

1 for (each F e !F) do 

2 construct interaction graph Dp] 

3 for (each weakly connected component oi Dp) dio 

4 if (it does not contain any old feature set node) 

5 find a sink node G; 

6 if {ind{F,G) = FALSE) 

7 return “feature interaction detected” ; 

8 for (each new feature set F in G - F) do 

9 construct interaction graph Dp] 

10 for (each weakly connected component of Dp) do 

11 find a sink node G; 

12 it {ind{F,G) = FALSE) 

13 return “feature interaction detected” ; 

14 return “feature interaction free” ; 



7 CONCLUDING REMARKS 

We have proposed a formal framework for a study of feature interaction prob- 
lem. We investigated conditions and algorithms for testing features for freedom 
from interactions, with an eye towards minimizing the number of tests that need 
to be performed. 

Certain features behave differently by design when other features are present. 
For example, the Caller ID feature will not display the ID of any caller who 
subscribes to the Caller ID Blocking feature. As a result, a feature set con- 
taining these features will not be independent based on our current definition. 
One way to address this issue is to modify our definition of independence: a 
feature set F is independent in F if the behavior of F is independent of the 
presence of any feature that F has no desired interactions with. Formally, let D 
be the set of features such that F and D have desirable interactions. ind{F^ E) 
if L{7rp\p{A)) = L{7Tp\(^EnD){A)). 

In the algorithms we invoked a subroutine call ind{-, •) to check for interac- 
tions. Also we need consistency checking. Formally, they require manipulations 
on the switch automaton, which is complex and often not available. Instead 
of explicitly constructing the switch automaton and performing projection and 
restriction operations for checking, we can apply conformance testing to the 
switch automaton, which is a “black-box” as follows. From the user automata 
with features of interest, we expect the structure and hence the languages ac- 
cepted by the switch automaton for the interaction and consistency checking. 
Therefore, we can apply a conformance test to the switch automaton to confirm 
its structure to the expectation and conclude the consistency and the presence 
or absence of feature interactions. 
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This work is an attempt to use formal methods to model and analyze proto- 
col feature interactions. We use automata to model both the switch and user 
behavior. They model the control portions of protocols well, but they are not 
powerful enough to succinctly model the data portions where variable values 
determine the system behavior and parameters are passed among system en- 
tities in messages. Extended, communicating, and parameterized finite state 
machines can be use to model more properly the real protocol systems. On the 
other hand, timers play an important role in determining protocol behaviors, 
and their presence further complicates the analysis of feature interactions. A 
lot of issues remain open in the research of feature interaction and much effort 
is needed before formal techniques can have a real impact on practical systems. 
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Abstract 

Partial search methods, like bitstate hashing or supertrace, allow formal verification tech- 
niques to be applied to problems which normally could not be solved by exhaustive verifica- 
tion. A high coverage (defined as the percentage of the reachable states actually explored by 
the verifier) is important since the higher the coverage the lower the probability that a protocol 
error is not detected. In literature sequential hashing is proposed to improve the coverage of 
supertrace (i. e. start supertrace repeatedly by using different hash functions). Since supertrace 
is included in many commercial and noncommercial verification tools, it is important to know 
where its limitations are and where there is potential for possible improvements. 

We present both theoretical and experimental results to measure the quality of sequential 
hashing with supertrace. Tests made with the SPIN validator with different classes of hash 
functions show that the additional number of states reached in successive runs decreases rapidly. 
A coverage of close to 1 is practically impossible. While all the hash functions have the same 
asymptotical behaviour universal hashing seems to be best. 

We present an analysis for the expected coverage of sequential hashing which explains ac- 
curately the experimental results. Our new mathematical model shows that the overlap of suc- 
cessive runs is much higher than predicted by former approaches. Additionally, it predicts that 
simple randomization strategies which in successive runs change randomly both the hash func- 
tion and the traversal order of the states can increase the coverage significantily. Experimental 
results show that our new algorithm, universal supertrace, which is based on such randomiza- 
tion techniques, outperforms the original supertrace and allows the coverage to be increased by 
a factor of up to 8-10. 
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1 INTRODUCTION 

In the reachability analysis protocol validation is done by state space search. Usually, the state 
space explosion makes a full exhaustive search impossible. Partial search methods, like bitstate 
hashing or supertrace (Holzmann, 1987, Holzmann, 1988), allow the time and space require- 
ments to be reduced efficiently when compared with exhaustive search methods. As a result, 
the verification of protocol state spaces with orders of magnitude greater than that which can 
be verified with traditional methods is possible. As a result, supertrace, or bitstate hashing, is 
included in many tools for automated protocol validation. 

Partial search methods risk that a protocol error remains undetected. Holzmann measures the 
quality of partial search methods by the coverage, where coverage is defined as the percentage of 
the reachable states actually explored by the verifier. The expected coverage equals the average 
probability that a particular state is not omitted. Therefore, it is imperative to reach the highest 
coverage possible. 

A natural method of improving the coverage is to start the supertrace algorithm repeat- 
edly with different hash functions. This method, referred to in (Holzmann, 1991) as multiple 
hashing and in (Holzmann, 1995) as sequential hashing, is supported by the SPIN validator of 
Holzmann. In theory, sequential hashing allows an expected coverage close to 1 to be achieved 
provided that the number of runs is sufficiently large. Up until now, it has not been determined 
how fast this approximation can really be done and which strategy results in the highest cover- 
age. To get a better insight, our paper presents both theoretical and experimental results in order 
to measure the quality of sequential hashing. 

Our tests made within the SPIN environment with different classes of hash functions show 
that in many cases the number of states additionally reached and checked by supertrace in 
successive runs decreases rapidly. While all the hash functions have the same asymptotical 
behaviour, universal hashing seems to be best. 

We present a mathematical analysis of the combined coverage of sequential hashing which 
overcomes the restrictions of former approaches and is more accurate. In addition to that, we 
prove that the overlap of the nodes generated in the different runs is much higher than assumed 
in former approaches which consider the generated states as randomly chosen from the set of 
all reachable nodes. Our model shows that the quality of sequential hashing suffers as a result 
of the fixed traversal order in which supertrace generates the state space. This drawback is of 
principal nature and cannot be overcome by better hash functions. 

Our model predicts that randomization techniques which change in each run both the hash 
function and the traversal order in the state space can increase the coverage by several times. We 
present a new algorithm, universal supertrace, which is based on such randomization techniques. 
Experimental results made with the SPIN validator show that randomized supertrace allows the 
coverage to be increased by a factor of up to 8-10 when compared with the original supertrace. 
We expect that additional improvements are possible using other strategies for changing the 
traversal order. 

This paper is structured as follows. Section 2 reviews the well-known supertrace algorithm 
resp. bitstate/double bitstate hashing and introduces universal hashing. Our experimental results 
of sequential hashing with different hash functions are presented in section 3. In section 4 we 
mathematically analyse sequential hashing and compare our results with earlier ones. In section 
5 we discuss our new algorithm, universal supertrace, its implementation and the experimental 
comparison with the original supertrace. Finally, the conclusion with suggestions for future 
research follows. 
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Figure 1 Double bitstate hashing. 



2 BACKGROUND 

In the reachability analysis the protocol is represented by an implicitly given state space, that 
is by a set of start states and by a set of possibly applicable transition. Protocol errors can be 
found by explicit enumeration of all the reachable states, that is by generating the states with 
either breadth-first or depth-first searches. Duplicate detection with hash tables is a widely used 
method of reducing the running time. The generated states are stored in a hash table which 
allows it to be determined whether or not a newly generated state x has been reached before 
and can be pruned now. Unfortunately, the number of states is often unmanageably large; this is 
the state explosion problem. For this reason in practice the total memory available for the hash 
table is often the limiting resource in verification. 

2.1 Supertrace Algorithm 

The bitstate hashing method or supertrace method introduced by Holzmann, 1988 aims at re- 
ducing the memory requirements for the hash table. In contrast to conventional methods where 
a state descriptor is stored completely, each state is represented by a bit which is addressed by 
the hash function h. Initially, all the bits of the table are set to 0. When a state x is inserted into 
the table the bit corresponding to the hash value h{x) is set to 1. When the algorithm generates 
a new state x and finds that the bit corresponding to this state is already set to 1 , it assumes that 
X has been visited before and prunes x without verification. If the assumption is incorrect an 
omission of the newly generated state x and potentially all of its successors occurs, since the 
search algorithm backtracks when it finds a state which has already been visited before. Usually 
supertrace is combined with a depth-first search with a typical threshold of 10"^ — 10^. 

The method above is referred to as single bitstate hashing, in contrast to double bitstate 
hashing (Holzmann, 1991) (see figure 1). In the latter one each state corresponds to two bits 
calculated by two different hash functions. The probability of an omission error is reduced 
since a hash collision now requires a collision on both bits. Both space and time requirements 
are reduced efficiently by supertrace. Space is reduced, because usually the state descriptor uses 
about 10^ bits which contrasts with the one or two bits if bitstate or double bitstate hashing is 
used. The running time is reduced, since duplicate test and insertion is done by a simple bit 
operation and in addition to this, hash collisions are not resolved. 
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2.2 Sequential Hashing 

The quality of partial search techniques like bitstate hashing or supertrace can be measured by 
the coverage which is defined as the quotient of the number of reached states and the number of 
states reachable by an exhaustive search. Since the higher the coverage, the lower the average 
probability for an omission error, partial search methods should aim at achieving the highest 
possible coverage. 

In (Holzmann, 1991) it is proposed that supertrace be started several times with independent 
hash functions. It is to be expected that different hash collisions will occur and as a result 
of this in each run different parts of the state space will be visited. In theory a coverage of 
arbitrarily close to 1 can be achieved, provided that a sufficiently large number of runs with 
independent hash functions are done. In the SPIN environment this method is implemented in 
order to increase the coverage of supertrace. 

2.3 Universal Hash Functions 

Since hash collisions are not resolved by bitstate hashing, it would be ideal if the used hash 
function could distribute the keys uniformly on the hash addresses. The key idea of universal 
hashing is to choose the hash function randomly from a suitable class of hash functions. If this 
class is carefully selected, a good average distribution can be guaranteed for an arbitrary set of 
hash keys. A state descriptor can be considered as a vector over the field of two elements. Let 71 
be a class of hash functions from A to 8 where >1 = {0, . . . , 2^ - 1} and = {0, . . . , 2^ - 1} 
for some integers k, 1. Recall, Ti is universal, if |{/i € 'H\h{x) = h{y)}\ < iTil/lBl for all x, 
y £ A . That is, H is universal if no pair of distinct keys collide under more than (l/|B|)-th 
of the functions. Universal hashing reduces the number of hash collisions on average. More 
precisely, if x G ^ and S is any subset of A, then the expected number of synonyms of x in 
is lower than or equal to |«S|/|H|. Note, that two keys x, y are called synonyms with respect to 
hash function h if h{x) = h{y). We present some examples used in our experiments. 

Class Til : Let the class Tii be defined by 

Til = {fa,b\fa,b : X -y ((ax 4-6) mod(p)) mod{\B\),a,h £ {0, . . . - l},a ^ 0}} 

where p is prime, p > \A\. Hi is universal (Carter and Wegman, 1979). Hi is suitable for 
applications where the bit strings which represent the keys can conveniently be multiplied by 
the computer. If the bit vector is too long as occurs in the protocol domain, then in (Carter and 
Wegman, 1979) the following construction is suggested . 

Class H 2 > Let the class H 2 be defined by 

H 2 {hf\ 1^/1 ^ ~ (^1 ) • • • 5 ^r) /l (xi) 0 . . . 0 /r- (Xt-), /l}...,/r £ Hi} 

where 0 is the exclusive-or operation. If r is a power of two, then H 2 is (nearly) universal 
(i. e. l/\B\ has to be replaced by {l/\B\) • (1 4- {\B\ -h l)/(p - 1)) in the definition above). If 
necessary, the state descriptor can be filled with O's to increase the length to a power of two. In 
our implementation we divided the bit vector x in integer blocks and selected p = 2^^ - 1 for 
Hi. 

Class Hzi Let M be the set of Boolean matrices with I colunms and k rows. Then we define 
H3 = ifc\fc : X X ♦ Me, Me £ M) 

where * denotes the matrix multiplication. Hs is also universal (Carter and Wegman, 1979). 
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Figure 2 Measured time for hash computation of class X relative to class HO (originally 
in SPIN) (a), relative to the verification time with class X (b). Verification time with class 
X relative to verification time with class HO (c). 



3 EXPERIMENTAL RESULTS 

In this section we present some experimental results made with SPIN. The experimental evalu- 
ation is based on the PFPT-protocol which was also used in (Holzmann, 1995) and is provided 
by the SPIN environment. To evaluate sequential hashing, we measured the coverage in a se- 
quence of tests in which the hash class and the parameters like state space size n, hash table 
size m and the number of runs q has been varied. In our experiments we used supertrace with 
the partial-order reduction methods supported by SPIN. This reduces the search effort, but has 
no effect on the evaluation. 

The following hash classes were used: The hash functions originally included in SPIN which 
are based on an efficient implementation of a CRC-calculation (here denoted by HO) (for more 
details see (Holzmann, 1991)), class 712 (H2), class Tis (H3), a class based on hashing by cyclic 
polynomials (HC) (Cohen, 1997) and a class based on hashing by general polynomial division 
(HP) (Cohen, 1997). In our release of SPIN (version 2.9.5) the number of CRC-polynomials is 
restricted to 32. Thus, we extended SPIN in order to supply a sufficiently large set of randomly 
generated CRC-polynomials (HZ). 

Figure 2 gives an overview of the running time necessary for the different hash functions. It 
shows that universal hashing doubles the running time when compared with CRC hashing (HO). 
We observed that the measured coverage of a single run differs only by a few percent between 
the classes, whereas when the number of runs is increased class H 2 works significantly better 
than all the others, especially if n m (this is the relevant case in practice). In our tests n 
is increased by simply increasing the depth-first threshold. The improvement by 7^2 grows as 
(n/m) or q grows (compare fig. 3-up and fig. 3-down). For n/m « 1/250 and q = 32, the 
coverage could be increased of up to 4 (see fig. 3-up). This can be explained as follows: The 
higher n/m is, the more important it is that the hash functions selected in successive runs are 
independent, and this is best achieved by the universal class 7 / 2 . This improvement cannot be 
increased indefinitely by increasing the search depth d. If n and m are fixed and d grows, the 
improvement first increases, but then gradually decreases (see fig. 3). Figure 5 reflects how 
coverage is improved by increasing m. If n > m, then doubling the hash table approximately 
doubles the measured coverage. This factor decreases rapidly with a decrease in n/m. 

Note: In our experiments the coverage could not be increased by a simple strategy of using 
alternatively a high (about 10^ — 10^) and a small (about 10^ — 10^) threshold in successive 
runs with the intention of traversing different parts of the search tree. 
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d=150, m=2'^10, q=32 




Transitions (in 1(X)0) 



d=150, m=2'^18, q=32 




Figure 3 Measured coverage in dependence of performed transitions. 



m=2'^14, q=32 




Figure 4 Measured coverage in dependence of search depth. 
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d=150, q=32 




Hash table size (in 2'^X) 



Figure 5 Measured coverage in dependence of hash table size. 

4 ANALYSIS 

In this section we present an analysis of bitstate and sequential hashing. Let m be the size of 
the hash table (measured in the number of bit addresses), q the number of runs and n the size 
of the state space. 

4.1 Related Work 

In (Holzmann, 1991) it is questioned whether sequential bitstate hashing can increase the cov- 
erage with the same system constraints. He answers with yes and gives an estimation of the 
coverage under certain conditions. He assumes that in each run exactly s states are generated 
and that the states generated in each run can be considered as randomly selected from the pool 
of reachable states. The combined coverage of two runs can then be computed as follows. A 
first run with a first hash function finds s from n states. A second run with a second hash 
function finds again s states, but makes a different selection. The combined coverage is greater 
than s, but lower than 2s since there is an overlap between both state sets. Under the above 
assumption the probability that a state x is generated in both runs is (s/n)^, hence the expected 
overlap is n • (s/n)^ and the combined coverage after two runs is 2s - s^/n. More generally, 
the probability that an arbitrary state x is not generated in a selected run is 1 — s/n, hence 
the probability that x is not generated in q independent runs is (1 - s/n)^, and hence x is 
reached with probability 1 - (1 - s/n)^. The expected number of reached states after q runs is 
n • (1 - (1 “ s/ny and thus the expected coverage is given by 

l-(l-s/n)^. (1) 

Equation (1) assumes that there are “ideal circumstances” which occur if the generated states 
can be considered as randomly chosen from the set of all reachable states. In (Holzmann, 1995) 
the reason for this is stated to be the fact that a graph representing a protocol state space is 
well-connected. We will show theoretically below that this is not sufficient. The overlap of 
successive runs is much higher and the combined coverage much smaller than predicted by (1). 
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In (Holzmann, 1995) there are presented lower and upper bounds for the expected coverage 
of a single run with bitstate and double bitstate hashing. These bounds are given by general 
constraints. Unfortunately, there are many pairs (n, m) for which either the lower bound or the 
upper bound is trivial or not defined. Our analysis does not suffer from such restrictions and 
works well even in the case n> m which is the relevant case. 

4.2 Our Approach 

In this subsection we present an analysis of the expected coverage of sequential hashing based 
on bitstate hashing. Double bistate hashing can be analyzed in a similar way. 

Equation (1) does not reflect the fact that the states are traversed in each run in depth-first 
order. There is an enumeration of the reachable states, say {xi\l < i < n), such that for each 
run and for all pairs ij, 1 < i < j < n, it is true: If both Xi and Xj are generated (reached), 
then Xi is generated before xj. Note, since supertrace is a partial search algorithm it is not 
guaranteed that x» and Xj are both generated. The following analysis takes into account that the 
states are traversed with respect to a fixed order. 

In a traversal of a protocol state space, many states are generated twice. Since we compute 
an upper bound of the number of generated states, w. 1. o. g. we may assume that duplicates have 
been pruned in the sequence above. Duplicates are states Xi, xj such that i ^ j, but x» = xj. 
Such a shorter sequence is achieved by removing repeatedly in the case of two duplicates the 
one with the higher index. Note that this shortened sequence generates the exact same set of 
states as the original sequence, since only duplicates have been pruned. However, using this 
shortened sequence the ratio of reached states to the number of transitions is estimated too 
optimistically. 

We assume, as in (Holzmann, 1991, Holzmann, 1995), that the hash values are distributed 
randomly and independently. Then we may consider the insertion operation as a random ex- 
periment which will be applied to each state with respect to the order xi , . . . , Xn. This is done 
in the following way. First, we compute h{xi) for state X{. If the bit addressed by h{xi) is 0, 
then Xi is newly generated and inserted into the hash table by setting bit /i(x,) to 1. Otherwise, 
Xi is considered as already generated and the hash table remains unchanged. If the insertion is 
successful, we say that the state has been reached, otherwise not. This reflects the fact that in 
the latter case state x, is considered as a duplicate and no verification test is done. This sim- 
plification ignores the fact that in the case of h{xi) = 1 (i. e. Xi is considered as a duplicate) 
the search tree is pruned and none of the successors of Xi are generated. As a result the ex- 
pected coverage of a single run is possibly too high. This is probably also true for the combined 
coverage of sequential hashing. 

Let E{i, k) represent the event that the hash table has i entries after the A:-th insertion try 
(of state Xjfe). Then event E{i, k) follows from event E{i — 1, A; — 1), if Xk is inserted, and it 
follows from event E(i^ k — 1), if the A;-th insertion fails. This gives the following reccurence. 



p{E{i,k)} = p{E{i,k)\E{i-l,k-l)}p{E{i-l,k^l)} 

-\-p{E{i, k)\E{i, k-1)}^ p{E{i, k - 1)} (2) 

for i > 0, A: > 0 and with initial values p{E{0, 0)} = 1, p{E{i, 0)} = 0, for i > 0, and 
p{E{-lj k)} = 0 for A; > 0. (p{B\A} denotes the probability for B under condition A.) It is 
p{E{i^ k)\E{i — 1, A; — 1)} = (m — i -f l)/m (since there are m — (i — 1) free hash positions) 
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and p{E{i, k)\E{i, k — 1)} = i/m (since there are i occupied hash positions). Thus, (2) is 
replaced by 

p{E(i,k)} = - ■ p{E{i, fc - 1)} + ~ ^ ^ p{E{i - 1, fc - 1)}. (3) 

m m 

Letp(i, k) denote the probability that Xk is inserted (with the k-ih insertion operation) under 
the precondition that the hash table has i entries after the A;-th insertion. These values can be 
computed by 



p{ijk) = p{E{i^k)\E{i — \^k — ' p{E{i — l^k — 

= ^^^-^p{Eii-l,k-l)}. (4) 

m 

The probability p{k) that Xk is inserted is therefore given by the sum of all probabilities 
p(i, k)y that is p{k) = p{i, k). The expected number of reached elements, provided that 
the elements are inserted with respect to the order (xi, . . . , Xn), is • p{k)) and the 

expected coverage after n insertions, denoted by a(n), is given by: 



a(«) = ^ • ^P{k)- (5) 

fc=i 

A comparison between the expected coverage of a single run computed with Holzmann's 
equations and (5) is given in figure 6. While both Holzmann’s upper bound and our estimation 
measure the coverage (of DTP-protocol) too optimistically (Holzmann, 1995), our estimation 
is more accurate. Note that our estimation predicts that bitstate hashing is better than double 
bitstate hashing if the state size is greater than the table size (more precisely, if n > 0.965 • m). 
This reflects quite accurately the empirical results given for DTP-protocol in (Holzmann, 1995). 

Let us compute the combined coverage of q runs. The probability that state x^ is not reached 
in q runs is (1 — p{k)y (provided that the hash values are independent). Hence, the probability 
that Xk is reached in q runs is given by Pq{k) = 1 — (1 — p{k)y. As a result, the expected 
coverage is given by 

n n 

n ^ n ^ 

fc=l k=l 

Of course, each state x is generated with probability 1 — e if a large enough value of q is 
chosen. But in practice this can require an unacceptable amount of time. 

The following diagrams summarize a comparison between the expected coverage of q runs 
computed with (1) and with (6). For fair comparison, we have to replace s/n in (1) by a(n) the 
expected coverage of a single run. Figure 7 and 8 shows how the number of reached states grows 
in dependence of the state space size and the number of runs. The coverage measured with (1) is 
much higher than when computed with (6). This contradicts the assumption that the states can 
be considered as selected randomly from the set of all reachable states. Figure 7 corresponds 
with figure 3 since increasing the threshold increases the number of reachable states. The figure 
shows that coverage grows slowly while the state space grows exponentially with the search 
depth. In the best case (n > m) doubling the table size doubles the coverage (as measured for 
class H 2 ). 
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Figure 6 Comparison of the expected coverage of a single run with supertrace estimated 
with Hoizmann’s equations and our approach (" — ” indicates when either no upper or no 
lower bound is defined and is to be replaced by the trivial bound 1 or 0 resp.). 
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Figure 7 Hoizmann’s versus our approach: Expected coverage of sequential hashing in 
dependence of n. 
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Figure 8 Hoizmann’s versus our approach: Expected coverage of sequential hashing in 
dependence of q. 
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Figure 9 Hoizmann’s versus our approach: Expected coverage in dependence of hash 
table size. 
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5 UNIVERSAL SUPERTRACE 



5.1 Theory 



The hash function is used as a parameter which is changed for each run of sequential hashing 
with supertrace while the traversal order in which the states are generated remains unchanged. 
Thus, the question is: Can the combined coverage of sequential hashing be increased if in each 
run both the hash function and the traversal order of the states are changed. The answer is Yes. 

Recall that universal hashing, for example, follows a general principle in order to get a good 
performance, that being a good distribution of the inserted keys. This principle suggests not to 
use a single algorithm for solving a class of problems, but rather a suitable set of algorithms 
should be provided from which one particular algorithm is chosen randomly in order to solve 
a given problem instance. This method is able to give a bound, which is independent of the 
input, for the average performance of the class of algorithms. Such a bound is valuable when 
it is better than the performance of any known single algorithm in that algorithm's worst case. 
We follow a similar principle to get a better coverage of bitstate hashing. 

Let Sn be the permutation group of n elements and the sequence xi, . . . , Xn be an explicit 
enumeration of all the reachable states. Let 5 C 5n be a subset. Then we assign each a £ S 
a sequence A^: • • • ? which represents the order in which the states are traversed. 

Note that there are permutations a £ Sn which do not correspond to a possible traversal order 
of an exploration tree, since a state x is always visited before its successor states will be visited. 
Let ^5 be the class of all the sequences a £ S. 

A natural way of changing the traversal order is as follows: Fix a subset S and a class of 
hash functions % and for each new run randomly choose both the hash function h £ 'H and 
the permutation a £ S (with equal probabilities) and explore the state space with respect to 
traversal order Aa and hash function h. We compute below the expected coverage when this 
strategy is applied to sequential hashing. 

First, let q = 1: It is easy to see that for a particular run the expected coverage, denoted 
by Q 5 ,i, is equal to the coverage of the original supertrace. The coverage is given by the sum 
^^^iP(ct(A;)) provided that a £ S is selected. The expected coverage averaged over all 
permutations is 



' ' <tGS fc=l ' ' <t£S <res 



Note that the expected probability that the state Xk is visited is given by 

' cres 



Let q > 1: Let us compute the expected coverage for q runs. Since we assume that the hash 
functions are independent, the probability that a selected state Xk is reached in at least one run, 
if the permutations cn , . . . , cr^ are selected, is given by 

1 - (1 - p(cn(k))) • (1 - p{<T 2 {k))) ■...■{!- p(a,(fc))) (9) 

The expected coverage of q runs if the sequence ai , . . . , is selected is 

n 

i V (1 - (1 - p(cTi(fc))) • (1 - p{a2{k))) • . . . • (1 - p(<T,(fc)))). 
n ^ 

/e = l 



( 10 ) 
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The expected coverage averaged over all sequences of q permutations (cri, . . . , € 5^ 
provided that each sequence is chosen randomly with equal probability, here denoted by as,q, 
is 

n 

(cri,...,aq)£S^ k=l 

By changing the summation order, we obtain 

n 

as,g{n) = -y^ps,,(fc) ( 12 ) 

k=i 

where 



PsAk) = 1 ^ Y1 il-{l-p{<rx{k)))-...il-p{ag{k)))) (13) 

(cTl,...,(Tg )€59 



which is the expected probability that Xk is reached after q runs. By induction over q it can 
be proven that 



n 



(14) 



<765 



Optimization problem: The problem now is to find a suitable subset S such that the com- 
bined coverage of q runs would be maximized. An upper bound for the expected coverage is 
given by the following optimization problem under constraints. Consider the system 

n 

f{yi,--,yn) = -(V]yj)-c (15) 

n 

7 = 1 

»(yi, -.,l/n) = iV(l-(l -?/,)«)) (16) 

n 

7 = 1 

where pj G [0, 1], 1 < j < n. A maxima of g under the condition / = 0 is given by 
Vd = c, 1 < j < n. This optimization problem applied to 



/( 2 /l,---,J/n) 

s(»/i,--,yn) 



^(^%) - ^(^pU)) 

n ^ n 



Qs,,(n) 



where yj = (l/|5|)(^^ggP(<T(j))), I < j <n yield a maxima for 



n 

yj = (l/n)(^p(7)) = a{n) = as,i(n), 1 < j < n. 
7 = 1 



(17) 

(18) 



This maxima corresponds with the (impossible) choice 5 = 5n. Then as,q{n) is equal to 
(1). We can conclude that (1) is an upper bound for the expected coverage to be achieved by 
such randomization methods. 
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Figure 10 Expected coverage of universal supertrace versus original supertrace. 
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Figure 11 Comparison of expected coverage of universal supertrace versus original super- 
trace (for q = 64, m = 2^®). The measured coverage of universal supertrace relative to 
that of original supertrace. 



But how to select S in practice? A natural way of changing the traversal order is as follows: 
Keep the depth-first order, but for each reached state x change randomly the order in which the 
immediate successor states of x are visited. Let us call this strategy combined with (double) 
bitstate hashing universal supertrace. We have computed the expected coverage in the case 
that the exploration tree has a constant branching factor b (that is, that each state has exactly b 
immediate successor states). Surprisingly, the expected coverage comes very close to the upper 
bound (1). The higher the branching factor the higher the coverage, but even for 6 = 2 the 
coverage is very close to the upper bound (see figure 10). 

5.2 Implementation and Experimental Results 

We have implemented our new algorithm, universal supertrace, in the context of the SPIN val- 
idator. Fortunately, only slight extensions of the original supertrace were necessary. The main 
extension consisted of a function which allowed the order in which the immediate successor 
states are visited to be changed randomly. In SPIN each state refers to a chain of possibly appli- 
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cable transitions. This chain reflects the order in which the successor states are generated. We 
included in SPIN a function which generates pointers to the transitions of the actual transition 
chain and changes the order randomly. In contrast to original supertrace, universal supertrace 
generates the successors in respect to this changed order. 

It must be guaranteed that the order in which the successors of a state x are generated can be 
restored if the search backtracks to x in order to continue the search with the next successor of 
X. In the original supertrace, this order is fixed during the search. Thus it is sufficient to store 
only a pointer to the transition to be performed next on the depth-first stack. In contrast to this, 
universal supertrace changes for each state x the original order of the transitions to be applied 
to X. For this reason, for each state x the new transition order has to be stored on the depth-first 
stack. This can be done in a space efficient way. We use a random function which is called up 
with a randomly generated initial value for each state x on its first visit in order to generate a 
new order in its immediate successors: equal initial values lead to equal transition orders. It 
then suffices to store only those initial values with which the random function has been called 
up in order to generate the order of the successors to be applied to x. This leads to an additional 
space requirement of 0{d) where d is the search depth. 

For evaluation, we made several tests with different parameters by using CRC-hashing with- 
out partial-order reduction. It seems that the maximal factor of improved coverage achieved 
with universal supertrace grows when the number of runs and the search depth are increased. 
For example, universal supertrace improves the coverage by a factor of up to 4.9095 compared 
with the original one for q = 32, m = 2^^ and by a factor of up to 8.7905 for q = 64, 
m = 2^® (see figure 11). If we compare the ratio of reached states to performed transitions 
(coverage/transitions) as a measure of how quickly new states are generated, the improvement 
is still higher. For example, in the first case this factor is increased of up to 5.9739 and in the 
second case by up to 14.2580 (see figure 11). Similar results are obtained if additionally the 
partial-order reduction method in SPIN is combined with universal supertrace. 

6 CONCLUSION 

This paper is intended to give better insight into the quality of bitstate and sequential hash- 
ing. We have presented an analysis of the expected coverage of bitstate and sequential hashing 
which is more applicable and much more accurate than former approaches (Holzmann, 1991, 
Holzmann, 1995). Our experimental tests and our analysis shows that the quality of the original 
supertrace suffers as a result of the fixed order traversal used in supertrace. We have presented a 
new algorithm, universal supertrace, which randomly changes in successive runs both the hash 
function and the traversal order. Theoretical and experimental results show that universal su- 
pertrace outperforms the original supertrace (Holzmann, 1987, Holzmann, 1988) and improves 
the measured coverage by a factor of up to 8-10. 

We expect that other strategies for changing the traversal order will have potential for addi- 
tional improvement which may be the subject of our future research. The mathematical analysis 
developed in this paper can be applied in a similar way to other partial search methods, such 
as hashcompact (Stem and Dill, 1996, Stem and Dill, 1996a), and would help to clarify under 
which circumstances hash compact is to be preferred. 
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Abstract: We present a new algorithm for automatic test generation for mul- 
ticast routing. Our algorithm processes a finite state machine (FSM) model of 
the protocol and uses a mix of forward and backward search techniques to gen- 
erate the tests. The output tests include a set of topologies, protocol events and 
network failures, that lead to violation of protocol correctness and behavioral 
requirements. We target protocol robustness in specific, and do not attempt to 
verify other properties in this paper. We apply our method to a multicast rout- 
ing protocol; PIM-DM, and investigate its behavior in the presence of selective 
packet loss on LANs and router crashes. Our study unveils several robustness 
violations in PIM-DM, for which we suggest fixes with the aid of the presented 
algorithm. 

1.1 INTRODUCTION 

Network protocol errors are often detected by application failure or perfor- 
mance degradation. Such errors are hardest to diagnose when the behavior is 
unexpected or unfamiliar. Even if a protocol is proven to be correct in isolation, 
its behavior may be unpredictable in an operational network, where interaction 
with other protocols and the presence of failures may affect its operation. 

The complexity of network protocols is increased with the exponential growth 
of the Internet, and the introduction of new services, such as IP multicast. In 
addition, researchers are observing new and obscure, yet all too frequent, fail- 
ure modes over the internets; such as routing anomalies [1, 2], and selective 
loss over LANs [3]. Such failures are becoming more frequent, mainly due to 
the increased heterogeneity of network components. 
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Many researchers have developed protocol verification methods, to ensure 
that certain properties of a protocol hold. Much of this work, however, was 
based on abstract mathematical models, with assumptions about the network 
conditions that may not always hold in today’s Internet. To date, little effort 
has been exerted to formulate practical methods and tools that aid in the 
systematic testing of multicast protocols. 

In this study, we propose a new method for automatic test generation, geared 
towards the study of protocol robustness in the presence of packet loss and 
network failures. In particular, we try to answer the question ”is the protocol 
robust to specific failures ?” However, we do not attempt to develop a general 
verification method. 

We borrow from well-established chip testing technologies and apply them 
to network protocols. We refer to our method as the fault-oriented test gener- 
ation (FOTG). Starting from a given fault, the necessary topology and event 
sequences are established, that drive the protocol into error states, using for- 
ward and backward search techniques. As a case study, we apply FOTG to a 
real multicast routing protocol; PIM-DM [4], that has been deployed in parts 
of the Internet. We are particularly interested in multicast routing protocols, 
because they are vulnerable to failure modes, such as selective loss, that have 
not been traditionally studied in the area of protocol design [3]. 

The rest of this paper is organized as follows. Related work is discussed in 
section 1.2. Section 1.3 provides method overview and definitions. Section 1.4 
describes our algorithm in detail, and summarizes the results of our case study. 
Conclusion is given in section 1.5. 

1.2 RELATED WORK 

There is a large body of literature dealing with verification of protocols. Ver- 
ification systems typically address well-defined properties -such as safety (e.g. 
deadlock freedom), liveness (e.g. livelock freedom), and responsiveness (e.g. 
timeliness) [5]- and aim to detect violations of these properties. 

In general, the two main approaches for protocol verification are theorem 
proving and reachability analysis [6]. Theorem proving systems define a set 
of axioms and relations to prove properties mathematically. Theorem proving 
includes model-based (e.g. Z [7]) and logic-based ioimdlisms (e.g. Nqthm [8]). In 
general, however, the number of axioms and relations grows with the complexity 
of the protocol. We believe that these systems will be even more complex, and 
perhaps intractable, for multicast protocols. Moreover, these systems work with 
abstract specifications, and hence tend to abstract out some network dynamics 
that we will study; such as selective packet loss and router crashes. 

Reachability analysis algorithms [9], on the other hand, try to generate and 
inspect all reachable protocol states. Such algorithms suffer from the ‘state 
space explosion’ problem, especially for complex protocols. To circumvent this 
problem, state reduction and partial search techniques [10] could be used. These 
algorithms, however, do not synthesize network topologies. Reduced reachabil- 
ity analysis has been used in the verification of cache coherence protocols [11], 
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using a global FSM model. We adopt a similar FSM model and extend it for 
our approach in this study. 

In [3] we have proposed a simulation-based STRESS testing method, based 
on heuristics and topological equivalences to reduce the number of simulated 
scenarios. However, we did not address automatic generation of topologies 
and events. Work in this paper complements our previous work, and may be 
integrated with the STRESS framework as part of its scenario generation. 

VLSI chip testing [12] uses test vector generation to detect single-stuck 
faults. Test vectors may be generated based on circuit and fault models, using 
the fault-oriented process, that utilizes implication techniques for line justifi- 
cation. We adopt some implication concepts for our method, and transform 
them to the network protocol domain. We note that chip testing is performed 
for a given circuit, while a protocol must work over arbitrary and time varying 
topologies, adding a new dimension to the test generation problem. 

1.3 METHOD OVERVIEW AND DEFINITIONS 

The input to our method is the specification of a protocol, its correctness re- 
quirements, and a definition of its robustness. In general, protocol robustness is 
the ability to respond correctly in the face of network failures and packet loss. 
Usually robustness is defined in terms of network dynamics or fault models. 
A fault model represents various component faults; e.g. packet loss, or ma- 
chine crashes. The desired output is a set of test-suites that stress the protocol 
mechanisms according to the robustness criteria. 

Our method produces tests based on a model of the protocol. This section 
describes the model used and gives an overview of the case study protocol; 
PIM-DM. 

1.3.1 System Model and Test Definition 

The system consists of network and topology elements and a fault model. 

Elements of the network consist of multicast capable nodes and bi-directional 
symmetric links. Nodes run same multicast routing, but not necessarily the 
same unicast routing. The topology is a V-router LAN modeled at the network 
level; we do not model the MAC layer. 

A fault, is a low level (e.g. physical layer) anomalous behavior, that may 
affect the protocol under test. An error is the failure of a protocol to meet its 
design requirement (e.g. duplicate packet delivery). 

Faults include: a) Loss of packets due to queue congestion or failure, b) 
Loss of state, e.g. uni/multicast tables, due to failures or crashes. Loss duration 
varies with the nature of the failure, c) Delays due to transmission, propagation, 
or queuing delays. Some delay problems may be translated into sequencing 
problems (see section 1.4.6). 

Usually, a fault model is defined in conjunction with the protocol’s robustness 
criteria. A design requirement for PIM is to be robust to single protocol message 
loss, which implies correct transitions from one stable state to another, even 
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in the presence of single message loss. We also study the momentary loss of 
state. To analyze erroneous behavior, we consider single message loss per test 
sequence. 

A test input pattern is defined as a 3-tuple ‘< Topology^ Events^ Faults >’; 
where Events is a sequence of host events; e.g. join, leave, or send packet, and 
the topology and faults as defined above. 

Test Sequence Definition, Given sequences T =< Ci,e 2 ,...,en > and 
T' =< ei,e 2 ,...,ej,/,ejfc,...,en >, where ei is an event and / is a fault. 
Let P{q,T) be the sequence of states and stimuli of protocol P under test 
T starting from the initial state q. V is a test sequence if final P{q,T') is 
incorrect; i.e. the stable state reached after the occurrence of the fault does 
not satisfy the protocol correctness conditions (see section 1.3.2) irrespective of 
P(g,T). In case of a fault-free sequence, where T = T', the error is attributed 
to a protocol design error. Whereas when T ^ T', and final P{q,T) is correct, 
the error is manifested by the fault. This definition ignores transient protocol 
behavior. 

1,3.2 PIM-DM 

As a case study, we apply our method to a version of the Protocol Independent 
Multicast-Dense Mode (PIM-DM) [4] protocol. 

Multicast routing protocols deliver packets efficiently to group members by 
establishing distribution trees. PIM-DM uses broadcast-amd-prune to establish 
the tree. In this mode of operation, a multicast packet is broadcast to all leaf 
subnetworks. Subnetworks with no local members send prune messages towards 
the source(s) of the packets to stop further broadcasts. Routers with new 
members joining the group trigger Graft messages towards previously pruned 
sources to re-establish the branches of the delivery tree. Graft messages are 
acknowledged explicitly at each hop using the Graft-Ack message. PIM-DM 
uses the underlying unicast routing tables to obtain the next-hop information, 
which may lead to situations where there are multiple forwarders for a LAN. 
The Assert mechanism resolves these situations and ensures there is at most 
one forwarder for the LAN. 

In this study we target protocol robustness errors. We are interested mainly 
in erroneous stable (i.e. non-transient) states. We assume that protocol errors 
and correctness conditions are provided by the specification. 

PIM Protocol Errors: A protocol error may manifest itself in one of the 
following ways: 1) black holes: consecutive packet loss between periods of packet 
delivery. 2) packet looping. 3) packet duplication. 4) join latency: excessive time 
taken by a receiver to start receiving packets. 5) leave latency: excessive time 
taken after a receiver leaves the group to stop the packet flow down pruned 
branches. 

Gorrectness Conditions: These conditions are necessary to avoid errors dur- 
ing stable states in a LAN environment: 1) If there exists routers expecting 
packets from the LAN then there must exist a forwarder for the LAN, to pre- 
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vent data loss (e.g. join latency or black holes). 2) The LAN must have at most 
one forwarder at a time, to prevent duplicates. 3) If there exists no routers ex- 
pecting packets from the LAN there must not exist a forwarder for the LAN, 
to prevent leave latency. 4) The delivery tree must be loop-free. We do not 
consider looping in this study, as it is not a local behavior. 

1.3.3 The Protocol Model 

We represent the protocol by a finite state machine (FSM), and the LAN by a 
global FSM model (GFSM), as follows: 

I. FSM model: A deterministic finite state machine modeling the behavior 
of a router Ri is represented by the machine Mi = (Q,Sj,(5j), where: Q is 
a finite set of state symbols, Ei is the set of stimuli causing state transitions; 
and. Si is the state transition function Q x Ei Q, 

II. Global FSM model: With respect to a particular LAN, the global state 
is defined as the composition of individual router states. The behavior of a 
LAN with n routers may be described by the global FSM Mg = 

n 

where: Qg\ Qi x Q 2 x • • • x Qn is the global state space, Eg: |J Sj is the set of 

stimuli causing the transitions; and 6g: is the global state transition function 
Qg xEg Qg, 

1.4 APPLYING THE METHOD 

Fault-oriented test generation (FOTG) targets specific faults. Starting from a 
given fault, FOTG attempts to synthesize topology(ies) that may experience 
an error, and a sequence of events leading to the error. 

The faults studied here are single message loss, and loss of state: 

1. For a given message, the algorithm uses the protocol model to identify 
a set of stimuli and states needed to stimulate that message, and the possible 
states and stimuli elicited by the message. This set of states form the global 
system state to be inspected. The algorithm is repeated for each message. 

For loss of state, the global state is constructed from the mechanisms neces- 
sary to create the state, and the algorithm is repeated for each state. 

2. Subsequent system states are obtained, through a process called forward 
implication, after the fault is included in the implication rules. Forward im- 
plication is the process of inferring subsequent states from a given state. The 
subsequent stable state is checked for errors. 

3. If an error occurs, an attempt is made to obtain a sequence of events 
leading from an initial state to the error state, if such state is reachable. Such 
process is called backward implication. 

Details of these algorithms are presented in section 1.4.5. 

1.4.1 PIM-DM Model 

Following is the model of a simplified version of PIM-DM. 
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I. FSM model. Mi = (Qi,Si,Si) 

For a specific source-group pair, we define the states w.r.t. a specific LAN 
to which the router Ri is attached. For example, a state may indicate that a 
router is a forwarder for (or receiver expecting packets from) the LAN. 



A. System States (Q). Possible states in which a router may exist are: 
State Symbol Meaning 



Fi 

F iJTimer 

NFi 

NHi 

^ HiJi'irner 

NCi 

EUi 

EDi 

Mi 

NMi 



Router i is a forwarder for the LAN 

i forwarder with Timer Timer running 

Upstream router i is not a forwarder, but has entry 

Router i has the LAN as its next-hop 

same as NH{ with the Timer Timer running 

Router i has a negative-cache entry pointing to the LAN 

Upstream router i does not have an entry; i.e. is empty 

Downstream router i does not have an entry; i.e. is empty 

Downstream leaf router with no state, and an attached member 

Downstream leaf router with no state and no attached members 



The possible states for upstream and downstream routers are as follows: 



Q _ I {Fi, Fi^Timer 1 N Fi, EUi} if the router is upstream, 

I {NHi, NHi_Timer,NCi, Mi, NMi, EDi} if the router is downstream. 

B. Stimuli (S). The stimuli considered here include transmitting and re- 
ceiving protocol messages, timer events, and external host events. Only stimuli 
leading to change of state are considered. For example, transmitting messages 
per se (vs. receiving messages) does not cause any change of state, except 
for the Graft, in which case the Rtx timer is set. Following are the stimuli 
considered in our study: 

1. Transmitting messages: Graft transmission (GraftTx) 

2. Receiving messages: Graft reception (GraftRcv), Join reception {Join), 

Prune reception (Prune), Graft Acknowledgement reception (GAck), Assert 
reception (Assert), and forwarded packets reception (FPkt). 

3. Timer events: these events occur due to timer expiration (Exp) and in- 
clude the Graft re-transmission timer (Rtx), the event of its expiration (Rtx Exp), 
the forwarder-deletion timer (Del), and the event of its expiration (DelExp). 

The expiration of a timer is implied as (Timer Implication) when the timer is 
set. 

4. External host events (Ext): include host sending packets (SPkt), host 
joining a group (HJoin ov HJ), and host leaving a group (Leave or L). 

E = {Join, Prune, Gra ftTx^Gra ftRcv,GAck, Assert, FPkt, Rtx, Del, SPkt,HJ, L} 

II. Global FSM model. An example global state for a topology of 4 routers 
connected to a LAN, with router 1 as a forwarder, router 2 expecting pack- 
ets from the LAN, and routers 3 and 4 have negative caches, is given by 
{Fi,NH2,NC3,NC^}. 
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1.4.2 Transition Table 

The global state transition may be represented in several ways. Here, we choose 
a transition table representation that emphasizes the effect of the stimuli on the 
system, and hence facilitates topology synthesis. The transition table describes, 
for each stimulus, the conditions of its occurrence. A condition is given as 
stimulus, and state or transition, (denoted by stimulus. st at e/trans); where the 
transition is given as start State •-> endState. At least one pre-condition is 
necessary to trigger the stimulus. In contrast, a post-condition for a stimulus is 
an event and/or transition that is triggered by the stimulus, in the absence of 
faults (e.g. message loss). A ‘(p)’ indicates a possible transition or stimulus, and 
represents a branching point in the search space, orig, dst^ and other indicate 
the origin of the stimulus, its destination, and other routers, respectively. For 
example, a Join reception: a) is caused by the reception of a Prune from 
another router, with the originator of the Join in NH state, and b) causes dst 
to transit into Fdst if it exists in Foei or NF state (other transitions are left out 
for simplicity). Following is the transition table for the global FSM discussed 
earlier. 



Stimulus 


Pre-cond (stimulus.state/trans) 


Post-cond (stimulus.state/trans) 


Join 


PruneQ^jiQj- ,N H Q-pig 


F dst-Del Fdst ^ ^ Fdst Fdst 


Prune 


L.NC.FPkt.NC 


F dst F dst-Del '{p)*! other 


GraftTx 


HJ.(NC NH), 
RtxExp.{NH_ntx — > NH) 


GraftRcy.{NH NH_Rtx) 


Gruftficy 


GraftTx-{NH ^ NH_Rtx) 


GAck.{N Fdst Fdst) 


GAck 


GraftRcv-F 


^ Fdst-Rtx ^ ^ Fdst 


Assert 


F Pktp^fiQ-p .F orig^ 


(p) ^ot/ier ^ FFpifieri 




AssertQiJiQj. .F orig 


(p)Assertother 


FPkt 


Spkt.F 


Prune.{N M NC), 

ED NH, M -> NH, 
FHottier F other ^{p) Assert 


Rtx 


RtxExp 


Graft'x'x-{NHQ'pig_jitx ^ FHoj^ig) 


Del 


DelExp 


Forig-Del ^ NF orig 


SPkt 


Ext 


FPkt.{EUorig Forig) 


HJoin 


Ext 


NM ^ M,GraftTx-{NC -> NH) 


Leave 


Ext 


M -> NM, Prune.(NH NC), 
Prune.(N H Rtx NC) 



1.4.3 State Dependency Table 

To aid in test sequence synthesis through the backward implication procedure, 
we construct what we call a state dependency table. This table does not con- 
tain additional information about the protocol behavior to that given by the 
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transition table, and is inferred automatically therefrom. We use this table to 
improve the performance of the algorithm and for illustration. 

For each state, the dependency table contains the possible preceding states 
and the stimulus from which the state can be reached or implied. To obtain this 
information for a state 5, we search the post-condition column of the transition 
table for entries where the endState of a transition is S. In addition, a state 
may be identified as an initial state (I.S.). The initial states for this study 
include {EU,ED,NM}. 

Following is a partial state dependency table: 



State 


Possible Backward Implication (s) 




Fi 


,^Pktother jyijr 17 Join 

< hUi,i ^i.Deh< 


NFi, • 4 ^ EUi 


Fi^Del 


Prune „ 
i Pi 




NFi 


Del _ Assert _ 

< Fi^el,< Fi 




NHi 


NHi.nt., J^NCi,l^ Mi, 


,^EDi 


NHi_ntx 






NCi 


FPkt xriir ^ TT ^ TT 

i NMi^i NHi_jiixi'^ NHi 







In some cases, multiple states need to be simultaneously implied in one 
backward step, otherwise an LS. may not be reached. To do this, the transitions 
in the post-conditions of the stimulus are traversed, and any states in the global 
state that are endStates are replaced by their corresponding startStates. For 

example, {Mi,NMj,Fk} {NHi,NCj,Fk}. 

1.4.4 Defining stable states 

As mentioned earlier, we are concerned with stable state (i.e. non-transient) 
behavior. To obtain erroneous stable states, we need to define the transition 
mechanisms between such states. We introduce the concept of transition clas- 
sification and completion to distinguish between transient and stable states. 

Classification of Transitions. We identify two types of transitions; exter- 
nally triggered (ET) and internally triggered (IT) transitions. The former is 
stimulated by events external to the system (e.g. HJoin or Leave), whereas 
the latter is stimulated by events internal to the system (e.g. FPkt or Graft). 

We note that some transitions may be triggered due to both internal and 
external events, depending on the scenario. For example, a Prune may be 
triggered due to forwarding packets by an upstream router FPkt (which is an 
internal event), or a Leave (which is an external event). 












101 



A global state is checked for correctness at the end of an externally triggered 
transition after completing its dependent internally triggered transitions. 

Following is a table of host events, their dependent ET events and their 
dependent IT events: 



Host Events 


SPkt 


HJoin 


Leave 


ET events 


FPkt 


Graft 


Prune 


IT events 


Assert, Prune, 


GAck 


Join 




Join 







Transition Completion. To check for the global system correctness, all 
stimulated internal transitions should be completed, to bring the system into 
a stable state. Intermediate (transient) states should not be checked for cor- 
rectness (since they may violate the correctness conditions set forth for stable 
states, and hence may give false error indication). 

The process of identifying complete transitions depends on the nature of the 
protocol. But, in general, we may identify a complete transition sequence, as 
the sequence of (all) transitions triggered due to a single external stimulus (e.g. 
HJain or Leave). Therefore, we should be able to identify a transition based 
upon its stimuli (either external or internal). 

At the end of each complete transition sequence the system exists in either 
a correct or erroneous stable state. Event-triggered timers (e.g. Del, Rtx) fire 
at the end of a complete transition, satisfying the Timer Implication. 

Also, according to the above completion concept, the proper analysis of be- 
havior should start from externally triggered transitions. For example, analysis 
should not consider a Join without considering the Prune triggering it and its 
effects on the system. Thus the global system state must be rolled back to the 
beginning of a complete transition (i.e. the previous stable state) before ap- 
plying the forward implication. This will be implied in the forward implication 
algorithm discussed later, to simplify the discussion. 

1.4.5 FOTG details 

As previously mentioned, our FOTG approach consists of three phases: I) syn- 
thesis of the global state to inspect, II) forward implication, and III) backward 
implication. These phases are explained in more detail in this section. 

FOTG starts from a given fault. The faults we address here are message 
and state loss. 

Synthesizing the Global State. 

Starting from a fault (i.e. the message or state to be lost), and using the 
information in the protocol model (i.e. the transition table), a global state is 
chosen for investigation. We refer to this state as the global-state inspected 
(G/), and it is obtained for message loss as follows: 

1. The global state is initially empty and the inspected message is initially 
set to the message to be lost. 
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2. For the inspected message, the state (or the start State of the transition) 
of the post-condition is obtained from the transition table. If the state does 
not exist in the global state, and cannot be implied therefrom, then it is added 
to the global state. 

3. For the inspected message, the state (or the endState of the transition) 
of the pre-condition is obtained. If the state does not exist in the global state, 
and cannot be implied therefrom, then it is added to the global state. 

4. Get the stimulus of the pre-condition of the inspected message. If this 
stimulus is not external {Ext), then set the inspected message to the stimulus, 
and go back to step 2. 

Note that there may be several pre-conditions or post-conditions for a stim- 
ulus, in which case several choices can be made. These represent branching 
points in the search space. 

At the end of this stage, the global state to be investigated is obtained. 

For state loss, the state dependency table is used to determine the message 
required to create the state, and the topology constructed for that message is 
used for the state. This is illustrated later in this section. 

Forward Implication. 

The states following Gj (i.e. where i > 0) are obtained through forward 
implication. We simply apply the transitions, starting from G/, as given by the 
transition table, in addition to implied transitions (such as timer implication). 
In case of a message loss, the transition due to the lost message is not applied. 
If more than one state is affected by the message, then the space searched is 
expanded to include the various selective loss scenarios for the affected routers. 
Backward Implication. 

If an error occurs, backward implication attempts to obtain a sequence of events 
leading to G/, from an initial state (/.5.), if such sequence exists; i.e. if G/ is 
reachable from LS. 

The state dependency table is used in the backward search. Backward steps 
are taken for the components in the global state G/, until an initial global state 
(i.e. a state with all components as LS.) is reached, or the termination criteria 
(if any) is met. 

Figure 1.1 shows the above processes for a simple example of a Join loss. 
Following are the steps taken for that example: 

Synthesizing the Global State 

1. Join: startState of the post-condition is NF^st => Gj = {NFk} 

2. Join: state of the pre-condition is NH{ => Gj = {NHi,NFk}, goto Prune 

3. Prune: startState of the post-condition is Fk which can be implied from NFk in Gj 

4. Prune: state of the pre-condition is NCj Gj = {NHi^NFk-tNCj}, goto L 

5. the startState of the post-condition is NH which can be implied from NC in Gj 
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Forward implication 

without loss: Gj = {NHi,NFk,NCj} G/+i = {NHi,Fk,NCj} 

loss w.r.t. Rj: {NHi,NFk,NCj} — )■ G/+i = {NHi, NFk, NCj} error 
Backward implication 

Gi ^ {NHi,NFk,NCj} G/_i = {NHi,Fk,NCj} G,^2 = 

{Mi,Fk,NMj} Gi-s = {Mi,EUk,NMj} G/_4 {N M,, EUk, NMj) = 

I.S. 

Losing the Join by the forwarding router Rk leads to an error state where 
router Ri is expecting packets from the LAN, but the LAN has no forwarder. 



Stimulus Pre-conditions Post-conditions 




error state 

backward implication <— Gj- Gj+ — > forward implication 



Figure 1.1 Join topology synthesis, forward /backward implication 



1.4.6 Summary of Results 

We have implemented an early version of the algorithm in the NS/ VINT envi- 
ronment (see http://catarina.usc.edu/vint) and used it to drive detailed sim- 
ulations of PIM-DM therein, to verify our findings. In this section we briefly 
discuss the results of applying our method to PIM-DM. The analysis is con- 
ducted for single message loss and momentary loss of state. For a detailed 
analysis of the results see [13]. 

Single message loss. We have studied single message loss scenarios for the 
Join, Prune, Assert, and Graft messages. For brevity, we partially discuss our 
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(I) no loss 



(II) loss of Graft (jjj) ^ 

interleaved Prune 



Figure 1.2 Graft event sequencing 



results here. For this subsection, we consider non-interleaving external events, 
where the system is stimulated only once between stable states. The Graft 
message is particularly interesting, since it is acknowledged, and it raises timing 
and sequencing issues that we address in a later subsection, where we extend 
our method to consider interleaving of external events. 

Join:. A scenario similar to that presented in section 1.4.5 incurred an error. 
In this case, the robustness violation was not allowing another chance to the 
downstream router to send a Jain. A suggested fix would be to send another 
prune by F^ei before the timer expires. 

Prune:. In the topology above, an error occurs when Ri loses the Prune, 
hence no Jain is triggered. The fix suggested above takes care of this case too. 

Assert:. An error in the Assert case occurs with no downstream routers; 
e.g. Gi = {Fi,Fj}. The design error is the absence of a mechanism to prevent 
pruning packets in this case. One suggested fix would be to have the Assert 
winner schedule a deletion timer (i.e. becomes Fdci) and have the downstream 
receiver (if any) send Jain to the Assert winner. 

Graft:. We did not reach an error state when the Graft was lost, with non- 
interleaving external events. 
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Interleaving events and Sequencing. A Graft message is acknowledged 
by GAck, and is robust to message loss with the use of Rtx timer. Adversary 
external conditions are interleaved during the transient states and the Rtx 
timer is cleared, such that the adverse event will not be overridden by the Rtx 
mechanism. 

To clear the Rtx timer, a transition should be created from NHmx to 
NH which is triggered by a GAck according to the state dependency table 

{NH i NHmx)^ This transition is then inserted in the event sequence, 

and forward and backward implications are used to obtain the overall sequence 
of events illustrated in figure 1.2. In the first and second scenarios (I and II) 
no error occurs. In the third scenario (III) when a Graft followed by a Prune 
is interleaved with the Graft loss, the Rtx timer is reset with the receipt of 
the GAck for the first Graft, and the systems ends up in an error state. A 
suggested fix is to add sequence number to Grafts, 

Loss of State. We consider momentary loss of state in a router. A ‘CrasN 
stimulus transfers any state ‘X’ into ‘EU’ or ‘ED’. Hence, we add the following 
line to the transition table: 

Stimulus Pre-cond Post-cond (stimulus.state/trans) 

Crash Ext {NM, M, NH, NC, NHmx} ^ ED, {F, FoeU NF} ^ EU 

The FSM resumes function immediately after the crash (i.e. further tran- 
sitions are not affected). We analyze the behavior when the crash occurs in 
any router state. For every state, a topology is synthesized that is necessary 
to create that state. We leverage the topologies previously synthesized for the 
messages. For example, state Foei may be created from state F by receiving 

a Prune {Foei < T"). Hence we may use the topologies constructed for 

Prune loss to analyze a crash for F^ei state. 

Forward implication is then applied, and behavior after the crash is checked 
for correct packet delivery. To achieve this, host stimuli (i.e. SPkt, HJ and 
L) are applied, then the system state is checked for correctness. 

In lots of the cases studied, the system recovered from the crash (i.e. the 
system state was eventually correct). The recovery is mainly due to the nature 
of PIM-DM; where protocol states are re-created with reception of data packets. 
This result is not likely to extend to protocols of other natures; e.g. PIM Sparse- 
Mode [14]. 

However, in violation with robustness requirements, there existed cases in 
which the system did not recover. In figure 1.3, the host joining in (II, a) did 
not have the sufficient state to send a Graft and hence gets join latency until 
the negative cache state times out upstream and packets are forwarded onto 
the LAN as in (II, b). 

In figure 1.4 (II, a), the downstream router incurs join latency due to the 
crash of the upstream router. The state is not corrected until the periodic 
broadcast takes place, and packets are forwarded onto the LAN as in (II, b). 
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SPkt SPkt 




(a) (b) 

(I) (II) (III) 



Figure 1.3 Crash leading to join latency 



SPkt 




(a) (b) 

(II) (III) 



Figure 1.4 Crash leading to black holes 



1,4.7 Limitations 

The FOTG algorithms require a pre/post-condition global transition table, like 
the one presented in this paper. Generating such table from a conventional 
single router I/O FSM is part of our on-going work. 

Currently the GFSM used in this study only models LANs. In our future 
work we will attempt to extend the model for regular and random topologies. 

The LAN topologies constructed are inferred from the mechanisms specified 
by the transition table of the GFSM. The algorithm will not construct topolo- 
gies resulting from non-specified mechanisms. For example, if the Assert mech- 
anism was left out (due to a design error) the algorithm would not construct 
{Fi,Fj} topology. So, FOTG (as presented here) may be used to evaluate be- 
havior of specified mechanisms in the presence of network failures, but is not a 
general protocol verification tool. 

1.5 SUMMARY AND FUTURE WORK 

We have presented a new method for automating the robustness testing of 
multicast routing protocols, in the presence of network failures. 
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We do not claim nor attempt to provide mathematical proof of protocol 
correctness or verification. Rather, we have targeted protocol robustness and 
endeavored to systematize its testing and analysis for a particular domain; 
multicast routing. 

Drawing from chip testing and FSM techniques, our method synthesizes 
the protocol tests automatically. These tests consist of the topology, event 
sequences and network faults. The following techniques were used to automate 
each of the test dimensions: 

Topology synthesis: using the state transition table, our method synthesizes 
N - router LAN topologies necessary to generate protocol messages or states, 
in terms of a global system state. 

Fault investigation: from the global state, forward implication is used to test 
the behavior of the system in the presence of faults. 

Sequence of events: if an error is found, backward implication constructs a 
sequence of events leading to the erroneous state, which is used to analyze the 
protocol behavior. 

Timing problems: we have presented an example of transforming a timing 
problem into a sequencing problem to analyze acknowledged messages. 

We have conducted a case study for PIM-DM, and found several scenarios 
in which the protocol behaved erroneously. 

Our method may also be applicable to other protocols that can be repre- 
sented by the global FSM model given in this paper. 

We are in the process of conducting a quantitative analysis and evaluation 
of our method in terms of complexity and completeness; i.e. the number of 
topologies synthesized, state transitions traversed and faults covered. We are 
also investigating complexity reduction techniques by introducing equivalence 
classes of states and topologies, using counting equivalence and repetition con- 
structors [11]. 

Future directions of this research include applying the FOTG method to 
other multicast protocols, including end-to-end performance analysis, extending 
the method to apply to topologies containing multiple LANs, and to include 
other network failures. 
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Abstract 

In a testing environment, where an lUT communicates with multiple entities, a tester 
may have differing degrees of controllability on the interactions between these entities 
and the lUT: directly controllable, semicontrollable, or uncontrollable. In this paper, 
a graph conversion algorithm is introduced that offers the testability of both the 
directly and semicontrollable inputs, while avoiding race conditions. Although, for 
the most general case, the graph conversion results in an exponentially large number 
of nodes, practical considerations make the converted graph size feasible. Currently, 
this methodology is being applied to generate tests for MIL-STD 188-220B, which 
increases the number of testable state transitions from approximately 200 to over 700. 
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1 INTRODUCTION 

Due to increasing complexity of communication protocols, automated genera- 
tion of conformance tests based on the formal descriptions has been an active 
research area [Ural, 1992] - [Sarikaya et al., 1987]. One problem that exists in 
today’s conformance testing stems from the limited controllability of an Im- 
plementation Under Test (lUT), which almost always renders certain protocol 
features untestable. Ideally, testers should be able to generate every possible 
input that is defined in the Finite State Machine (FSM) modeling an lUT. 
Similarly, all outputs generated by an lUT should be observable by the testers. 

Unfortunately, in practice, these two situations often are not possible. 
Testers may not have a direct access to all interface (s) in which the lUT accepts 
inputs. Typically, for an (N)-layer lUT, an exposed interface exists only be- 
tween the lUT and the (N-l)-Service Provider [IS9646, 1991]. Interfaces with 
the upper layer, or with the peer entities (such as timers, etc.) are not directly 
accessible. In such cases, the interactions that involve these not directly con- 
trollable interfaces introduce non-determinism and/or race conditions during 
testing, leaving certain portions of the lUT model untestable. 

Consider an (N)-layer lUT communicating with an entity FSMi that does 
not have interfaces directly accessible by the tester (i.e., the tester cannot apply 
inputs to FSMi). In some cases, FSMi can be utilized to generate otherwise 
not directly controllable inputs to the lUT. An output from the lUT to the 
FSMi can force the FSMi to generate a response as the desired input from 
FSMi to the lUT. If the tester can apply an appropriate input to the lUT, 
the lUT, in turn, triggers such an interaction between the lUT and FSMi. 
In this case, some of the interfaces become semicontrollable (as opposed to 
uncontrollable) . 

Another difficulty that arises when there are multiple interfaces interacting 
with the lUT is the possible occurrence of race conditions. If an lUT moves into 
a state at which several inputs from different interfaces are waiting, choosing 
which input is consumed first may cause non-determinism. 

There are many real-life protocols that possess either semicontrollable in- 
puts, or race conditions, or both, due to a tester’s limited control over the 
interactions between the lUT and other communicating entities. For example, 
in MIL-STD 188-220B [188-220B, 1998], over 70% of the transitions cannot be 
directly controlled. The race conditions can be shown in the IEEE 802.2 LLC 
Connection Component protocol [ISO8802-2, 1994]. 

Some problems due to the limited controllability over the lUT are addressed 
in the literature. Testing embedded systems [Rayner, 1987, Timohovich, 1993] 
where uncontrollable events may take place is discussed in [Phalippou, 1992] 
and [Cavalli et al., 1996]. The ferry clip testing method by [Zeng et al., 1989], 
and the Astride testing method by [Rafiq and Castanet, 1990] are introduced 
to enhance the controllability of inputs to an lUT. Deriving test sequences by 
combining the lUT and a single entity communicating with it into a global FSM 
are proposed in [Timohovich, 1993]. The testing system considered in this paper 
does not assume any user-defined entities within the SUT (as implied by [Zeng 
et al., 1989] and [Rafiq and Castanet, 1990]). Also, a global FSM is not built 
to avoid state explosion problem. 




113 




Figure 1 (a) Testing lUT with multiple interfaces; (b) Testing (N)-layer lUT with an 

(N+l)-layer semicontrollable interface. 



This paper introduces a methodology that utilizes an lUT’s semicontrollable 
interfaces while avoiding the race conditions. An algorithm is presented to 
modify an lUT’s directed graph representation such that the semicontrollable 
portions of the lUT become directly controllable, where possible. In the most 
general case, such a graph conversion results in an exponentially large number 
of nodes. However, special considerations such as a small number of interfaces 
interacting with an lUT, and diagnostics considerations can make the problem 
size feasible for most practical cases. 

The algorithm presented in this paper is being applied to MIL-STD 188- 
220B protocol to generate conformance tests. Initial results are promising: the 
number of testable transitions increased to over 700 from approximately 200 
for the Class A - Type 1 Service Datalink module [Fecko et al., 1997]. 

This paper is organized as follows. Section 2 formally defines the control- 
lability problem^ which is practically motivated in Section 3 by examples from 
real-life protocols. Section 4 defines a system model for a testing environment 
with multiple interfaces with different degrees of controllability. Practical issues 
are introduced into this model in Section 5. An algorithm to modify an lUT’s 
graph so that semicontrollable interfaces can be fully utilized while avoiding 
the race conditions is presented in Section 6. In Section 7, the application of 
minimum-cost test sequence generation techniques is discussed. 

2 CONTROLLABILITY PROBLEM 

Consider a testing environment shown in Figure 1 (a). The System Under 
Test (SUT) contains an lUT, which interacts with F FSMs. FSMi, • • • , FSMf, 
implemented inside the SUT, interact with the lUT through interfaces 
hr ‘ The points at which a testing system can apply inputs to and 

observe outputs from the lUT are called points of control and observation 
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(PCOs) [IS9646, 1991]. Each lUT’s interface is associated with a full-duplex 
PCO through which inputs and outputs can be exchanged. The inputs can be 
of three different types: 

• directly controllable: a tester can directly apply the inputs to the lUT 
through the PCO 

• semicont reliable: a tester cannot directly apply the inputs to the lUT 
through the PCO. However, it is possible to utilize one of the FSMs 
interacting with the lUT to supply these inputs indirectly 

• uncontrollable: the inputs may be supplied through a PCO without any 
explicit action of the tester. This means that inputs may be generated 
during testing without the tester’s control 

The inputs at a given PCO can belong to one or more of these three types. 
If a PCO has any semicontrollable inputs and does not have any uncontrol- 
lable inputs, we say that its associated interface is semicontrollable. If there 
are no semicontrollable or uncontrollable inputs, the interface is called directly 
controllable. In this paper, without loss of generality, we consider that each 
interface has only one type of input: either directly controllable or semicontrol- 
lable. The analysis also is applicable to interfaces with a combination of directly 
controllable and semicontrollable inputs (excluding uncontrollable ones). 

A typical example of a directly controllable interface is a Lower Tester 
FSM [IS9646, 1991]. A timer FSM, whose only inputs come from an HIT 
(e.g., start, restart, and stop the timer), is a typical semicontrollable interface. 

In the testing framework of Figure 1 (a), the tester is unable to supply inputs 
directly to the HIT through interfaces /i, •••,//?’. Therefore, the interfaces 
/i, • • • , are only semicontrollable, provided that F5Mi, • • • , FSMp can be 
utilized to supply inputs to the lUT. On the other hand, the tester can apply 
inputs to the lUT directly by using a Lower Tester (LT), which exchanges 
N-PDUs with the lUT by using the (N-l)-Service Provider. The interface 
Iq between the LT and the lUT is therefore directly controllable (/q can be 
considered an interface between the LT and the lUT, because the (N-l)-Service 
Provider acts as a pass-through that does not alter inputs or outputs). 

To test the lUT’s transitions triggered by the inputs from U, the tester 
must use one of the directly controllable interfaces to force the lUT to generate 
outputs to li. These outputs are applied to FSMi at /^’s PCO. As response 
to these outputs, FSMi will send back inputs to the HIT through /*. These 
inputs will trigger the appropriate transitions in the HIT. 

Consider the SUT shown in Figure 1 (b). The LT, which exchanges N-PDUs 
with an (N)-layer lUT, represents a directly controllable interface /q. Since the 
interface I\ is not exposed in the SUT, a tester can neither directly apply 
inputs to the lUT nor observe the lUT’s outputs to the (N-hl)-layer. In this 
case, h is at best only semicontrollable. To apply (N-l-l)“layer’s inputs to the 
lUT through h , the LT must generate inputs to the lUT through its directly 
controllable interface Iq. In response, the lUT will generate outputs to FSMi 
through Ii. Subsequently, in response to these outputs, FSMi will generate 
inputs to the lUT at Ii . 

This paper addresses the problem of generating optimal realizable test se- 
quences in an environment with multiple semicontrollable interfaces. This prob- 
lem will be referred to as the controllability problem. 
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SUT 




Figure 2 802.2 Type 2 Connection Component LLC Specification [ISO8802-2, 1994] 



3 PRACTICAL MOTIVATION 

As motivation for solving the controllability problem, two real protocols where 
an SUT’s (N+l)-layer must be utilized indirectly to test certain transitions 
within the (N)-layer lUT are considered. They also illustrate an important 
point that must be taken into account while utilizing an (N+l)-layer indirectly 
- avoiding race conditions. 

MIL-STD 188-220B [188-220B, 1998] is a military standard for interoper- 
ability of command, control, communications, computers, and intelligence over 
Combat Net Radios. In the testing framework used to test 188-220B, the upper 
layers cannot be directly controlled. This makes the lUT’s transitions that are 
triggered by the inputs coming from the upper layer not directly testable. 

In fact, 70% of the transitions are based on semicontrollable inputs. Without 
indirect testing, test coverage would be seriously reduced. However, by applying 
the technique introduced in this paper, almost all (>95%) transitions defined 
in the specification can be tested (the number of testable transitions rose to 
over 700 from approximately 200 for the Class A - Type 1 Service Datalink 
module [188-220B, 1998, Fecko et al., 1997]). 

Figure 2 shows a portion of the IEEE 802.2 [ISO8802-2, 1994] LLC Type 
2 Connection Component. The SUT consists of the LLC layer lUT and the 
implementation of the upper layer (UL), whose FSM is semicontrollable. Tran- 
sitions T1 and T4 output a Data Judication to the UL. Transitions TO and T3 
require input Data^Request from the UL. 

Testing transition T3 requires the input Data-Request to be applied to the 
lUT. Since this input can only be applied from the UL, an indirect event trigger- 
ing sequence must be used. The UL FSM contains a transition with an input of 
Data Judication and an output of Data^Request. By generating Data Judication 
from the lUT to the UL, the tester can indirectly generate Data-Request. 
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No transition in Reject outputs a Data Judication to the UL. Therefore, a 
Data Judication must be sent to the UL while the lUT is in another state. Then 
the lUT must be moved into the Reject before the UL outputs its Data.Request, 
For example, one straightforward solution is to use transition Tl. The tester 
applies to the lUT an input LCMD with the appropriate parameters and flags. 
The lUT outputs a Data Judication to the UL. Then the tester brings the lUT 
to Reject state by applying an LCMD through transition T2. Now transition 
T3 will be triggered by Data-Request that by then has arrived from the UL. 

Unfortunately, this solution has a race condition: in the Normal state, after 
the Data Judication is output as a result of traversing Tl, if a Data-Request 
arrives from the UL before the tester applies T2’s input LCMD, then the 
Data-Request will be consumed by transition TO before transition T2 flres. 
To avoid this race condition after an indirectly generated Data Judication, the 
tester must And a way of moving the lUT to the Reject state through states 
in which a Data-Request cannot be consumed. Consider Await state with 
transition T4 that can be used to generate a Data-Indication. There is no 
race condition here, because the Await state cannot process a Data-Request. 
A tester has sufficient time to move the lUT to Reject state through transition 
T5, where a Data-Request buffered in the interface will trigger T3. 

As can be seen from this example, the lUT can move into a state where 
the lUT is forced to consume a previously buffered input. This creates a race 
condition if the test sequence requires that a different input be sent to the lUT 
by the LT. Therefore, a test sequence without such race conditions will not 
bring the lUT into a state where multiple inputs are pending (one from the 
LT, and others from the buffers). Instead, the test sequence should traverse 
the lUT transitions in an order that avoids these race conditions. 

4 MODELING TEST SYSTEMS WITH CONTROLLABILITY ISSUES 

Among the widely used specification formalisms to model protocol imple- 
mentations are labelled transition systems (LTS) and Finite State Machines 
(FSM) [Tretmans, 1996]. In an LTS, the inputs and outputs for a system are 
not distinguished, but instead represented as interactions. The LTS allows an 
interaction to occur if both an implementation and an environment are able to 
perform that interaction. 

An FSM, on the other hand, is a subset of an LTS where, for every state tran- 
sition, an input is coupled with one or more outputs (including a null output). 
In this paper, an FSM model, which is sufficient to model protocols with finite 
state space and deterministic behavior, is used to represent an implementation. 

Let us consider an lUT interacting with multiple semicontrollable interfaces. 
The goal of test generation in this environment is to derive a set of tests ex- 
ercising each transition in an lUT^s FSM at least once. Specifically, given a 
graph G representing an lUT’s FSM, we want to find a minimum-cost tour of 
G such that each transition is covered at least once. 

Given the graph G{V, E) representing an FSM model of an lUT with multiple 
semicontrollable interfaces, let us define the following parameters: 

• \V\ - number of nodes in G 

• F - number of semicontrollable interfaces interacting with the lUT 




SUT 
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Figure 3 lUT interacting with two semicontrollable interfaces. 

• Ti C E - subset of edges in G triggered by the inputs from the z-th 
semicontrollable interface 

• bi - buffer size (maximum number of inputs buffered) at the i-th. semi- 
controllable interface U 

• Ai - set of inputs triggering transitions in Ti 

• Oi - set of outputs of the lUT that force inputs in A{ to be buffered at li 

• Ci- number of different transition classes in the lUT triggered by inputs at 
li. Two transitions t\ and t2 belong to the same transition class Tij C Ti 
iff they both become fireable by the same input aij G Ai 

• Uij C E - set of transitions in the lUT with output Oij such that, in 
response to Oij , an input aij G Ai is buffered at li 

Let Ai = . . . ,ai,cj and Oi - {0^,1, . . . ,Oi,rnJ- Then the sets of Tij, Uij, 

Ti, and Ui, are defined formally as follows: 



def def 

Tij = {e E E : label{e) = aij /oij} Uij = {e E E : output{e) = Oij} 

Ti (J Tij Ui [J [/.., 

j=i i=i 

There may be several outputs in set Oi that force input aij to be buffered at 
li. For simplicity, let Oij denote any output forcing aij at li. Based on the 
above definitions, transitions triggered by the inputs from the semicontrollable 
interface li are divided into Ci classes, each corresponding to a distinct input 
that fires any transition within the class. No transition can belong to more than 
one Tij. Similarly, each transition can belong to only one Uij. In general, Tij 
and Uij may or may not be disjoint. 

Example : Consider the lUT of Figure 3 which is interacting with FSMi and 

FSM 2 through the semicontrollable interfaces h and h, respectively. The lUT’s 
FSM is described in Table 1. Transition el, triggered by input xi from the LT, 
generates output oij to FSMi. In response, FSM\ sends back input ai,i which 
triggers transition eS. (In general, Uij is the expected response to Oij.) e3, when 
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Edge name | Input from | Output to Edge name | Input from | Output to 



el 


LTlxi 


FSMiloi^i 


eS 


LT?X8 


F SM\\o\^2 


e2 


FSMi7ai,2 


F SM\\o\^2 


e9 


FSAf2?tt2,i 


LT\y^ 


e3 


F5Mi?ai,i 


FSM2\02,1 


elO 


LTlxio 


LTlyio 


e4 


FSAl270‘2,i 


LT\y4 


ell 


FSAfi?ai,2 


LTlyn 


e5 


LT?X6 


LT\y^ 


el2 


LT?xi2 


FSM2l02,l 


e6 


LT?X6 


LTlye 


el3 


LTlxis 


LTlyis 


e7 


LT?X7 


FSMi\oi^2 


el4 


LT?Xi4 


LT\yi4 



Table 1 Inputs and outputs for the edges of Figure 3. Alx denotes receiving input x 
from A. B\y denotes sending output y to B. 



traversed, outputs 02,1 to FSM2, which responds with input 02,1 triggering e4 or e9. 

02.1 is also output to FSM2 by el2, which is hred by the LT^s input x\2- Transitions 
el and eS, after being triggered by the LT’s inputs xj and xg, respectively, generate 
output oi,2 to FSM\. FSMi sends back input ai,2, which triggers either e2 or ell. 
e2 outputs oi ,2 to FSMi. Again, FSMi responds with input ai, 2 - On the other 
hand, transitions e5, e6, elO, el3, and el4, can be triggered directly by the LT and 
do not generate outputs to the semicontrollable interfaces. For this example, we have: 

• |V| = 3 i.e.. A, B, and C; F — 2 i.e., h and h; ci = 2, C2 = 1 

• Ti,i = {e3 }, Ti, 2 = {e2,ell}, T24 = {e4, e9}, Ti = Ti,i U Ti,2 = {e2,e3,ell}, 
T2 = T2,i = {e4, e9} 

• C/ 1,1 = {el}, C/ 1,2 = {e2,e7,e8}, C/ 2,1 = {e3,el2}, Ui = C/ 1,1 U C/ 1,2 = 
{el,e2,e7,e8}, U2 = C/ 2,1 = {e3,el2} 

• Ai = (ai, 1,01,2}, A2 = {o2,i}; Oi = {01,1,01,2}, O2 = {02,1} 

4.1 Buffer sizes at semicontrollable interfaces 

For now, let us assume that there exists a separate FIFO buffer in the semicon- 
trollable interface between the lUT and each interacting FSM. During testing, 
a buffer may be empty or store an arbitrary sequence of inputs to the lUT gen- 
erated indirectly through the i-th semicontrollable interface. Then the entire 
system can be modeled by G (which represents the lUT’s FSM) and the vari- 
ables (Ji , u; 2 , • • • , cof- a variable uji has a distinct value for each permutation of 
inputs that the f-th buffer can hold. 

If the buffer sizes at the F semicontrollable interfaces are infinite, each vari- 
able LJi can assume an infinite number of values. In this case, even the reach- 
ability analysis (deciding whether a given state is reachable from the initial 
state), which is an easier problem than finding a minimum-cost traversal of G, 
is undecidable [Davis et al., 1998]. Even if the buffer sizes are finite, in which 
case a;i,a; 2 , . . . jCOf have finite domains, the reachability analysis is PSPACE- 
complete for the most general case [Hopcroft and Ullman, 1979]. 

Given the difficulty of analyzing G and F variables, let us explore the pos- 
sibility of modeling the system as an FSM, represented by G {V ,E ). Each 
vertex in V is a tuple consisting of the original vertex in V and the set of 
values of variables o;i,cj 2 , • • • The maximum number of nodes \V \max is 
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|l^'|max = \V\ * Ylf=iB{i), where B{i) is the maximum possible number of 
states of the i-th buffer defined as follows: 

itSii 

In general, if each Ci = c > 1 and each bi = 6, then \V'\max = \V\ * 0{c^^), 
which indicates that the maximum number of nodes in G grows exponentially 
with the number of semicontrollable interfaces F and the buffer size b. Clearly, 
the conversion from G to G is not feasible for the general case. However, for 
the constrained environment, G can be constructed efficiently (Section 7). 

5 PRACTICAL CONSIDERATIONS FOR TEST SYSTEM 

5.1 Buffering inputs at semicontrollable interfaces during testing 

Although the model presented in Section 4 assumes that a semicontrollable 
interface consists of FIFO-type buffers, in practice this assumption may not 
hold true for all implementations. Typically, the interface is not part of a 
protocol specification. Vendors have the freedom of developing interfaces in 
different ways: in addition to (or instead of) FIFO-type buffers, they may have 
interrupt-driven mechanisms and any interface may have multiple buffers. 

Therefore, test sequences generated for an lUT with only FIFO-type buffers 
become non-deterministic for other lUTs using different types of interfaces. 

Example (cont’d): Consider a test sequence for the lUT of Figure 3: 

el4, el, e8, e3, e4, ell, el3, el2, e5, e9, e7, e2, el3, ell, el3, e6, elO, e6 (2) 

The underlined portion of the above test sequence traverses el, which results in input 
ai,i being buffered at h (Table 1 ). Subsequently, when e8 is executed with output 01,2 
to h, the buffer at h should contain [ai,i,ai, 2 ]- The lUT is expected to be in state 
C with e3 to be tested next. This sequence is only realizable under the assumption 
that inputs ai,i and ai ,2 are stored at h in the FIFO order, i.e., [ 01 , 1 , 01 , 2 ]- In 
practice, however, this may not be the case for all implementations. It is possible 
that, after traversing el and e8, the buffer will contain inputs in a different order, 
such as [oi, 2 , 01 , 1 ]. Then, after e8 is traversed, ell will be triggered by 01,2 instead of 
e3 being triggered by oi,i . e3 will cause the lUT to fail even if implemented correctly. 
Clearly, the test sequence (2) is not realizable without FIFO-type buffers. 

To eliminate this type of non-determinism in test sequences, the lUT model 
should have a buffer size bi = 1. Then, the maximum number of nodes in 
G becomes \V \max = \V\ * HiliCl + ^0- ^ testing environment, F, 

the number of semicontrollable interfaces, is expected to be small. For most 
cases, the (N)-layer HIT interacts only with an (N-(-l)-layer implementation 
and several semicontrollable timers. Typically, for each timer, the only output 
is the timeout, which defines Ci as 1. Therefore, for small F and q, the size of 
G is only a small multiplicant of G. 

Let us now consider the number of inputs that can be buffered simultaneously 
at all of an lUT’s semicontrollable interfaces. When we allow inputs being 
buffered simultaneously at several semicontrollable interfaces, even a buffer 
size equal to 1 may not prevent non-deterministic behavior during testing. 
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Example (cont’d): Consider a potential test sequence for Figure 3 generated 
for buffer sizes of 1 at h and h: 

el4, el3, el2, e7, e9,ell , el, elO, e3, e4, el2, e5, e9, e7, e2, el3, ell, el3, e6 

Although this sequence avoids the non-determinism due to buffer sizes shown previ- 
ously in (2), it may still be non-deterministic due to the lUT interacting with multiple 
interfaces simultaneously Consider the underlined portion of the above sequence. Af- 
ter el2 is traversed, input a 2 ,i is buffered at h. Traversing e7 results in ai ,2 being 
buffered at I\. Since Q 2 ,i was generated earlier than ai, 2 , transition e9 is expected 
to be triggered instead of e2. In reality, due to the unknown response time of the 
interfaces, 02,1 can be applied to the lUT earlier than, later than, or simultaneously 
with ai, 2 - In this case, the behavior of the lUT will be non-deterministic, thereby 
making the test sequence invalid. 

To avoid this type of non-determinism during testing, the model presented in 
Section 4 will be used to generate tests with the restriction that, at any time, a 
single input may be buffered in only one of the lUT’s semicontrollable interfaces. 
In such case, the maximum number of nodes is lV'|max = IV^I * (1 -f Ci). 

It is important to point out that, the minimum-length test sequences gener- 
ated for a restricted model will likely be longer than the minimum-length test 
sequences for the general model. However, restricted model tests can be used 
for testing implementations regardless of their interface structure. The intro- 
duced restrictions on the buffer size and on the number of buffered inputs help 
avoid non-deterministic behavior of the SUT during testing. Although the test 
sequence length is increased by these restrictions, the tests become applicable 
to many different SUT interface types, as further discussed in Section 7. 

5.2 Diagnostic issues during testing 

As presented in Section 2, during testing, an lUT typically interacts with several 
semicontrollable interfaces. Testing is performed under the assumption that 
all FSM implementations other than the lUT conform to their specifications. 
Otherwise, it is diflScult to tell whether failure occurs in the lUT, or in the 
external FSM implementation, or at the semicontrollable interfaces. 

Example (cont’d): Consider el4, el,e8,e3, which is the beginning part of 
the test sequence given in (2). When this sequence is applied to the lUT, traversal of 
el should cause FSMi to send back input ai,i. The lUT will move to state A with 
ai,i buffered at I\. Suppose that a faulty implementation incorrectly contains input 
ai ,2 instead of ai,i at I\. Then in state A transition e2 will be triggered by ai, 2 , 
and the lUT will move to state B instead of remaining in state A after el’s traversal. 
This will happen even when el and e2 are implemented correctly. The tester cannot 
distinguish whether el ’s or e2’s implementation is faulty, or FSM\ is not conformant 
to its specification, or I\ malfunctioned. 

This practical concern of making diagnostics easier suggests the following 
guideline: “Test as many transitions as possible without interactions at semi- 
controllable interfaces.” Transitions preferably should be tested when there are 
no inputs buffered at the semicontrollable interfaces. As a result of this ap- 
proach, a minimum-cost test generation can be formulated as a Rural Chinese 
Postman Problem [Lenstra and Kan, 1976], as discussed in Section 7. 
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Class 1: Class 2: Class 3: 




Figure 4 Classes of edges in G (dashed-lined outputs are optional). 



6 GRAPH CONVERSION FOR SEMICONTROLLABLE INTERFACES 

Recall from Section 4 that an SUT, represented by variables and 

graph G for an lUT, can be modeled as an FSM, represented by G {V\e'). 
In this section, an algorithm sketch for converting G and cji, • • • ,u;ir to G' is 
presented and briefly analyzed. (A detailed description of the algorithm along 
with its pseudocode is available in [Fecko et al., 1998]). Since the number of 
vertices in G is exponential with respect to the buffer size 6^, the algorithm is 
most applicable for small buffers (1 < < 3). 

As discussed in Section 6, the test sequence obtained from G constructed 
by the algorithm does not contain any race conditions. Recall from Section 3 
that a race condition occurs when an lUT consumes previously buffered input 
instead of an input defined by a test sequence. Therefore, a test sequence 
without race conditions will never bring the lUT into a state where there is 
a buffered input consumable in this state and a different input applied by the 
LT. Such a test sequence will test the lUT’s transitions in a specific order such 
that these race conditions will not occur. However, a test sequence of G may 
still have non-determinism (Section 5). A refinement of the graph conversion 
algorithm to eliminate non-determinism during testing is also presented. The 
graph G (y ,£ ) is built by the algorithm whose sketch is in Figure 5. Let 
Bi denote a sequence of inputs buffered at the i-th semicontrollable interface. 
Each state v e V has two components: the original state v £ V, and the 
current configuration of F buffers, i.e., v = {v,Bi, . . . , Bp). The algorithm 
constructs all possible buffer configurations with up to bi inputs buffered at 
!{. Given an original edge e = {v start, Vend) ^ E, and the current vertex v — 
{vstart,Bi ,. . . , Bp), a new vertex is created based on a new configuration 
B\ j • • • j Bp , i.e., v^^yj — {vend 5 B \ , > . • , Bp). The edge e — {v start , Vend) ^ E is 
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g\v\e’) = BUILD-EXPANDED-GRAPH {G{V,E),r) 

1. initialize r, root of g' , as (r, 0, • • • , 0) (root of G and 
configuration of empty buffers) 

2. initialize e' as empty set, and V* as {r } 

3. initialize Q, queue of vertices, as V 

4. repeat until Q is empty 

(a) extract v = {vstart^ , Bp) as first element from 

Q, where (^i , ^ Bp) is current configuration 

(b) for each outgoing edge e = (v start, Vend) ^ E do 

i. determine k, index of e's class 

ii. given {Bi , . . . , Bp) and Class k definition, construct: 

• new configuration '{B\, Bp) 

• new vertex = {Vend, , Bp) G v' 

• new edge = {v\ v^^^) G e' 

(c) include new edges in E iff inputs in (B \, . . . , Bp) can- 
not trigger other edges outgoing from Vstart 

(d) append to Q end vertices G V of new edges in- 

cluded in E 

5. remove from v' all vertices from which r cannot be reached 

6. remove from E all edges incident to such vertices 



Figure 5 Algorithm sketch for converting graph G into G . 

included in E' as = {v , The edge e e E belongs to one of the four 

classes depicted in Figure 4: 

Class 1: e is triggered by an input from and generates output (s) to an LT. In this 
case, e’s traversal does not modify the configuration {Bi , . . . ,Bp) of e’s start 
state, e is included in E unconditionally. 

Class 2: e is triggered by an input from an LT and generates an output Oq^i at Jg. e 
is included in Enew ouly when the number of inputs already buffered in Bq in 
the corresponding configuration of state (vstarti Bi, . . . , Bp) is smaller than the 
maximum allowable hq. The new configuration (J3i , . . . ^Bp) is obtained from 
{Bi , . . . , Bp) by appending Ug,/ to Bq. 

Class 3: e is triggered by from Ip and generates output(s) to an LT. e is included 
in Enew oiily when ap^k is the first element buffered in Bp in the corresponding 
configuration of state (u^tart, J5i, . . . , Bp). The new configuration (Bi, . . . , Bp) 
is obtained from (Bi, . . . , Bp) by deleting ap^k from Bp. 

Class 4: e is triggered by an input ap,jt from Ip and generates an output Og,/ at Iq. 

If e interacts with only one semicontrollable interface, i.e., p = q {Class 4a), 
/ 

then it is included in Enew only when e’s input Gp^k is the first element buffered 
in Bp in the corresponding configuration of state {vstart, Bi, . . . ^ Bp). Since 
Gp^k is first deleted from Bp, there is always room in Bp for Gp^i. If Ip and 
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Iq are different, i.e., p ^ q {Class 46), then e is included in E^ew only when 
it satisfies the inclusion conditions for both Classes 3 and 2 edges, as defined 
above. The new configuration (J3i, . . . , Bf) is obtained from {Bi, . . . , Bp) by 
applying rules for Classes 3 and 2 (in this order) . 

More complicated cases can be modeled as a combination of these four 
classes. For example, the case where an input x applied at Iq goes through 
lUT, FSMp, lUT, FSMq, and lUT, to produce an output y at /q, can be a 
combination of Classes 2 and 3. The cases where FSMp and FSMq directly 
communicate with each other are beyond the scope of this paper. 

It can be shown that G {V ) built by the algorithm of Figure 5 is 
a minimal valid representation of the system defined by G and variables 
[Fecko et al., 1998, Uyar et al., 1998]. The running time RT of 
the algorithm is shown [Fecko et al., 1998] to be: 

RT=i * Sl=i (^out{v)) = 0(c*’^ * |£;|) if c > 1 

\ 0((1 + bf) * doutiv)) = 0((1 + bf * \E\) if c = 1 

Based on the practical considerations discussed in Section 5, the algorithm can 
be refined so that at any given point in time there could be a single input 
buffered in only one of the buffers J5i, which yields a linear running time of 
RTref = 0{c*F*\E\). 

7 TEST GENERATION FOR PRACTICAL TESTING ENVIRONMENT 

Given graphs G{V, E) and G {V ' , E" ), our goal is to find a minimum-cost tour 
of G such that each original edge from G is covered at least once. Recall from 
Section 5 that G will likely contain multiple appearances of certain edges from 
the original graph G. Let E^ C E be the subset of edges in G such that 
each original edge in E is represented by at least one copy in E^. To build 
a minimum-cost tour of G covering each original edge in E is equivalent to 
finding a minimum-cost tour of G that includes each transition in E^ (the set 
of mandatory edges) at least once, and each transition in {E - E^) (the set 
of optional edges) zero or more times. This problem is known as the Rural 
Chinese Postman Problem [Lenstra and Kan, 1976]. 

The issue that arises in the case of multiple appearances of certain edges in 
G is which copies should be included in E^. Practical concerns discussed in 
Section 5 require that copies incident to nodes corresponding to configurations 
with empty buffers should be marked as mandatory. Note that when the buffer 
size in each semicontrollable interface is 1, each edge e that belongs to some Uij 
or Tij will appear in G only once, and therefore will be marked as mandatory. 
All other edges with a copy incident to the states in V whose second component 
is the configuration of empty buffers will be marked as mandatory in this copy. 
If no such copy exists, the edge will be marked as mandatory in all its copies 
with the presence of a buffered input. Therefore, each edge in E will be marked 
as mandatory in one or more appearances. 

[Aho et al., 1991] present a solution to the problem of finding a minimum-cost 
tour of G {V ,E ) covering subset of edges E^ C E . The sufficient condition 
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Figure 6 Graph transformation applied to the graph of Figure 3. Mandatory and optional 
edges appear in solid and dashed lines, respectively. 



for the existence of a polynomial-time solution is that induce a weakly- 
connected spanning subgraph of G . It can be easily shown that obtained 
in the manner described above is a weakly-connected subset of E . 

Example (cont’d): Consider the graph of Figure 3. After conversion to G 

(Figure 6), each state is replaced with at most four copies - each corresponding to 
the buffer configuration at a semicontrollable interface. Each edge e is annotated as 
e.x, where x = 0, 1, 2,3, depending on the input buffered in the e.x^s start state, as 
shown in Figure 6. Given graphs G and G , the sets E and E are as follows: 

E = {cl,e2,e3,e4, c5,e6, e7, e8,e9, el0,ell,el2,el3,el4} 

E = {el.O, e2.2, e3.1, e4.3, e5.0, e5.3, e6.0, e6.3, e7.0, e8.0, e9.3, 
elO.O, elO.l, el2.0, el3.0, el3.1, el3.2, el4.0, el4.1} 

To build the set of mandatory edges to be included in a test sequence, we adopt the 
approach discussed in Sections 5 and 7. In G , several edges appear multiple times: e5, 
e6, elO, el3, and el4. The edges in Figure 6 shown in solid are the mandatory edges 
that are incident to nodes that correspond to the case where both buffers are empty, 
i.e., e5.0, e6.0, elO.O, el3.0, and el4.0. The copies that can he traversed only when 
either buffer contains an input are shown in dashed line: e5.3, e6.3, elO.l, el3.1, el3.2, 
and el4.1. These are the optional edges, which will be included in the test sequence 
only when necessary. In this example we have: 

Ec = {el.O, e2.2, e3.1, e4.3, e5.0, e6.0, e7.0, e8.0, e9.3, elO.O, ell. 2, el2.0, el3.0, el4.0} 

Given the above sets E and Ec, the Aho et ai. technique gives the minimum-length 
test sequence for G shown in Table 2. Steps with (->) indicate that an edge is tested 
in this step. Note that, for simplicity, the UIO sequences [Sabnani and Dahbura, 
1988] are not included in this sequence. 
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Step I Edge name | Input from | Output to 



1 


el4 1 


LT?X\4 


LT\yi4 


2 


el3 


LTlxii 


LT\yi3 


-> 3 


e5 


LT?X5 


LT\y, 


-)> 4 


e8 


LT?xs 


FSMi !oi,2 


-> 5 


ell 


FSMi ?ai,2 


LT\yn 


^ 6 


el 


LT7xi 


FSMi !oi,i 


7 


elO 


LT7xio 


LTlyio 


-4 8 


e3 


FSMi?ai,i 


FSM2^.02,1 


^ 9 


e4 


FSM27a2,i 


LT\y4 


10 


el2 


LTlxi2 


F SM2\02^1 


11 


e5 


LT7xs 


LT\y, ’ 


12 


e9 


FSM27o2,1 


LTlyg 


-4 13 


e7 


LT1x7 


FSMi Joi,2 


14 


e2 


FSMilaia 


FSMi !oi,2 


15 


el3 


LT?Xi3 


LT\yi3 


16 


ell 


FSMi?ai^2 


LTlyii 


17 


el3 


LT?xi3 


LT\yi3 


^ 18 


e6 


LTlxe 


LTlye 



Table 2 Minimum-length test sequence for the lUT of Figure 3. 



8 CONCLUSION 

In this paper, a testing environment is considered where the lUT communicates 
with multiple entities with different degrees of controllability on generating in- 
puts. The inputs that these entities apply to the lUT may be directly con- 
trollable, semicontrollable, or uncontrollable. This paper introduces a graph 
conversion algorithm that takes full advantage of the semicontrollable inputs 
while avoiding race conditions. In a test sequence of such a modified graph, 
semicontrollable inputs become controllable (where possible). Although, in gen- 
eral, the graph conversion results in an exponentially large number of nodes, 
practical considerations can make the converted graph size feasible. 

Currently, this methodology is being applied to generate tests for MIL-STD 
188-220B. Without utilizing the semicontrollable inputs, the number of testable 
transitions for MIL-STD 188-220B Class the Class A - Type 1 Service Datalink 
module is approximately 200. With the presented methodology, initial results 
show that the number of testable transitions increases to over 700, a coverage 
of more than 95% of the transitions defined in the specification. 
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Abstract: A lot of researches have been made for an effective and efficient 

test case generation method. However, theoretical researchers and practical re- 
searchers follow the different goals and methods each other especially in the test 
case generation of real protocols. In this paper, we proposed a new framework 
and methodology for automatic test case generation of real protocols. They 
bridge between the theoretical and practical researches and try to bring together 
the best of theory and practice in test case generation. They can cope with the 
change of test environment and technical state. The key idea is the distributed 
analysis technique. We used both simulation and model analysis according to 
the context dependency of the sequence. We defined test coverage selection cri- 
teria of a protocol in an EFSM (Extended Finite State Machine) model and in 
an EEFSM (Expanded EFSM) model. We used three techniques to reduce the 
complexity of simulation: the depth first search with termination conditions, 
the partial supplementation technique and the partitioning technique. To show 
the efficacy of the proposed framework and methodology, we apply them to 
a real communication protocol, SSCOP (Service Specific Connection Oriented 
Protocol) for B-ISDN protocol. 

1 INTRODUCTION 

Since whether a communication protocol implementation conforms to its stan- 
dard specification or not is required to be tested, a great number of researches 
have been made in this area. A lot of studies among them are interested in test 
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case generation method for conformance test. To generate more effective and 
efficient test cases, they try to generate test cases with higher fault coverage 
and for data flows as well as control flows in protocols. But there are many 
problems in those studies. One of them is to overcome the difficulties due to 
the complex structure and many functions of communication protocols. For 
the purpose, many efforts to reduce the problem size have been made such as 
modeling or partitioning of a protocol into a simplifled structure, test selection 
and optimization. There is a trade-off relation between test coverage and the 
cost of test. Theoretical researchers, however, are more interested in the former 
issue. It is generally known that much time is required for the generation of test 
cases as well as the testing itself. Automatic test case generation is, therefore, 
one of the most important issues, because they will save much time. 

Several automatic or semi-automatic test case generation tools such as TGV, 
TVEDA, Test Gen and SaMsTaG have been developed and now they are under 
improvement (Doldi et a/., 1996; Grabowsky et al, 1997). They try to reduce 
manual efforts in the course of test by the power of FDT (Formal Description 
Techniques) and their related tools. They also naturally focus on generation 
of test suite in TTCN(Tree and Tabular Combined Notation) that is directly 
applicable to a real test. Most of them use the simulation technique to And 
out the sequences corresponding to the selected test purposes. The simula- 
tion technique can also give the values to complete the constraints of the test 
suites. Their developers, however, do not try to apply techniques of theoretical 
researches to them yet such as techniques for extending fault coverage of test 
cases. Theoretical researchers also try to develop automatic tools to generate 
test cases, but their tools are mostly for validation of their researches and for 
simple protocol with many assumptions. So it is nearly impossible to use them 
directly to generate test cases for real protocols. 

Like the most cases of other areas, in general, there is also a considerable 
gap between the theoretical approaches and the practical approaches in the 
area of conformance test. In industrial context, the most important goal is 
whether it can be applied to implementations and almost all the tests have 
real constraints such as deadline and the cost. In academic context, on the 
other hand, most of tests are free of constraints by some assumptions and the 
effectiveness and validity are the matter of primary concern. Their viewpoints 
to generation of test cases for real communication protocols show this gap well. 
Theoretical researchers will not use a real communication protocol as a tar- 
get protocol, because they are so much complicated and difficult to model or 
simplify properly. Practical researchers seldom use the theoretical methods in 
testing real protocols because they think the methods are impractical and irrel- 
evant for real protocols. Therefore, new test case generation framework to be 
able to use both the advantages of two approaches is required and we proposed 
a new framework for automatic test case generation and its methodology in 
this paper. 

The paper proceeds as follows: In section 2, we show the proposed test 
case generation framework. The next 3 sections explain the methodology of 
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test case generation in the framework: test coverage and test selection criteria 
are explained in section 3, the distributed analysis method in section 4 and 
reduction techniques of problem size in section 5. Section 6 shows the empirical 
results in applying the proposed method to B-ISDN protocol SSCOP(Ser-vice 
Specific Connection Oriented Protocol). We evaluate the method by comparing 
with related studies in Section 7. Finally conclusions and future works are given 
in section 8. 

2 OVERALL FRAMEWORK 

The characteristics of the required framework are as follows. They should be 
able to accept the requirements and viewpoints of the theoretical and prac- 
tical approaches. They should be also able to use the advantages of the two 
approaches and deal with newly developed theoretical techniques, various test 
environment and new complex protocols. Considering the above requirements, 
we proposed a new framework as shown in Figure 1. 




Figure 1 The proposed test case generation framework 

The target protocol specification is given in FDT such as SDL. The test case 
generation procedure is affected by two external factors: the test environment 
and the technical level. The test environment factor is for several constraints 
of practical testing and the technical level factor is for new results of theoret- 
ical or practical researches. These two factors decide variable elements of this 
framework. Test constraints like cost or deadline may decide the test coverage 
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of the test case generation method. Physical conditions of test system may se- 
lect the test method. Where the PCOs(Points of Control and Observations) of 
the given lUT (Implementation Under Test) or SUT(Sys-tem Under Test) exist 
will select the specific test method. By the selected test coverage and the test 
method, the test purposes of the test suite to be generated are decided. On 
the other hand, newly developed techniques of test case generation may solve 
the problems existed in the existing method. Theoretical studies or a lot of 
test experiences can develop the techniques. The test case generation method 
is developed by those techniques. Thus, this rather dark region ‘A’ containing 
the above two methods can allow manual decisions or manipulations, if needed 
by external constraints. The test coverage selection is explained in detail in 
section 3 and among the techniques those for reduction of problem size are 
explained in section 5. 

The core of the proposed framework is the distributed analysis method de- 
picted as the region ‘B’ in Figure 1. In general, while the practical tools to 
generate test suite in TTCN use simulation to find test cases refiecting test 
purposes, theoretical researchers try to derive test cases by modeling the speci- 
fication and its analysis. The simulation technique may take long time and the 
model analysis is incomplete now. Real communication protocols have several 
functions like a buffer management and a timer management that are difficult 
to model easily. The model analysis for all the protocol functions is incomplete 
and impractical but the analysis will be able to help to reduce the time of 
simulation, we think. So we used two techniques partially. The parts that are 
difficult for the model analysis are context dependent parts having predicate 
statements. Therefore the model analysis is in charge of context independent 
parts and the simulation technique is of context dependent parts. Section 4 
explains these techniques in detail. 

By the distributed analysis technique, the values of constraints in the test 
suite are decided and those results of the analyses are translated into an ab- 
stract test suite in TTCN. The selected test method, the techniques and other 
information for the generation process are reported as a methodology guide. 
This information is used for a new heuristic technique. 

3 TEST COVERAGE AND TEST SELECTION CRITERIA 

Lately as the protocol model used for test case generation of conformance test 
EFSM (Extended Finite State Machine) model is used in many cases, because 
the FSM (Finite State Machine) or LTS (Labeled Transition System) model can- 
not detect any error of data flows, and moreover may be impractical because 
of not considering executability of a test sequence. Therefore, test cases that 
can find the faults in data flows as well as control flows are required. In the 
data flow test of a protocol, Weyuker’s data selection criteria based on data 
flow analysis of software testing are widely used as fault coverage selection cri- 
teria(Weyuker and Rapps, 1985). But her software model is different from the 
general EFSM model of a communication protocol; data elements like def or 
use are usually considered to be only in edges in an EFSM model of a protocol. 
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Modification of the criteria is, therefore, required. The modified the data se- 
lection criteria for protocols with the test coverage criteria of control flow test 
are shown in Figure 2. 



all-paths 




Figure 2 The test data selection criteria of EFSM 



The major difference from the Weyuker’s is that the test cases satisfying 
all-p-uses or all-uses criterion cannot cover the test cases satisfying all-edges 
criterion. There can exist edges without data element such as def or use in an 
EFSM model of a protocol when we do not consider major states of FSM a 
kind of variables as usual cases in protocol testing. All the test cases satisfying 
all-uses criterion, therfore, do not have all the edges. We added one criterion in 
the relations, any -uses criterion. The definitions of those criteria are as follows. 

Definition 1 The test suite satisfies any-uses criterion iff for all uses of 
all the variable x whose edge number is m, there is at least one def-clear-path 
with respect to x from n to m, where n is the edge number of the def of the 
def-clear-path. 

Any-uses criterion can be used in some practical environments. The test 
coverage selection criteria of a control flow test depicted together show the re- 
lations with data selection criteria. Naturally transition identification criterion 
covers all- edges criterion and state identification criterion covers all-nodes crite- 
rion. Test cases satisfying transition identification criterion come to have all the 
uses of the variables and their prior defs in natural, in other words they have 
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at least one def-clear paths for each use. Therefore, transition identification 
criterion covers any-uses criterion. 

As we mentioned in section 2, we use simulation for context dependent anal- 
ysis. By simulation, the specification is transformed to a reachabiliy tree. The 
tree has normally many homogeneous states that were originally same states. 
To reduce the problem size, we use minimized EEFSM (Expanded EFSM) tree 
instead of the reachability graph as shown in Figure l(Henniger et aZ., 1995). 
The minimized EEFSM tree is generated by merging the homogeneous states 
having same data values in the reachability tree. In the minimized EFSM tree, 
the relations between test data selection criteria and test coverage selection 
criteria are changed as shown in Figure 3. 




Figure 3 The test data selection criteria of expanded EFSM 

In the minimized EFSM tree, there are still not a few homogeneous states, 
edges and data elements. Consequently, the total number of the states, edges 
and data elements is so large that too many test cases are required to satisfy 
the existing criteria. We, therefore, defined all-nh^du-paths^ all-nh-uses, all- 
nh-defs, any-nh-uses^ all-nh-edges, all-nh-node, nh-transition identification and 
nh-state identification criteria, where the word ‘nh’ means non-homogeneous. 
The defined criteria are equivalent to the criteria without ‘nh’ in the case of 
EFSM. 

In test coverage selection criteria for control flow test, we added p(n)-nh- 
transition identification criterion and (n)-nh-state identification criterion. A 
series of input parameter values in a test case that mahe the test case executable 
may not be unique. Finite or infinite number of values can be valid for the test 
case. Which values to select in generating the test case has been an important 
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issue in software testing or protocol testing. How to find out the exact set of 
values that makes the test case executable is a theoretical interest for many 
researchers but the problem turned out to be undecidable in normal cases. 
In case of simulation, it is difficult to find out the set of executable values. 
We get to know, by simulation, whether a series of specific values makes the 
test case executable or not only. But by using more than one test cases having 
different values of input parameters, we can generate a test suite with more test 
coverage. The p(n)-nh-transition identification criterion is satisfied by the test 
suite which has n test cases having different values for each input parameter. 
The (n)-nh-state identification criterion is for reduction of test case explosion by 
the state identification parts for all the states. The (n)-nh-state identification 
criterion is satisfied by the test suite that has the state identification parts for 
the specific n states. 

Most test case generation tools generate a test suite satisfying the nh- 
transition identification criterion while theoretic methods use ones having more 
test coverage such as the all-nh-du-paths criterion or the all-nh-uses criterion. 
The nh-transition identification criterion has high test coverage to cost ratio 
but if a test suite having more test coverage is required, the procedure of the 
next section will generate them effectively. 

4 DISTRIBUTED ANALYSIS METHOD 

All the constraint parts of a test suite in TTCN can be completed automat- 
ically by the distributed analysis method. This method uses two well-known 
techniques, the simulation and the modeling, as shown in Figure 1. Why is 
this method needed? Using only one of two techniques, which is usual, did not 
produce complete results. But two techniques are complementary each other. 
The modeling technique can reduce the size and time of the simulation tech- 
nique. On the other hand, the simulation technique can give the executable 
values of input parameters. Which technique to use to generate test cases for 
a certain sequence is decided by whether the sequence is context dependent or 
independent. A sequence is said to be context independent if the predicate of 
every transition in the sequence is independent of any control variable of the 
specification. The sequence that is not context independent is called a context 
dependent sequence. To know the executability of the sequence, simulation is 
required in most cases. 

The test case generation procedure using the distributed analysis method is 
shown in Figure 4. First, the protocol specification is modeled in an EFSM for 
model analysis. In this paper, we confined the analysis model to a single module 
EFSM without local signals. In case of the protocol specification that has com- 
municating multiple modules, each module is modeled an EFSM individually 
without considering concurrency between modules. Test case generation for 
a concurrent system is still an open problem. When the target EFSM model 
is built, several fundamental test components are generated by its analysis. 
The test components are the preambles to each state, the postambles from each 
state and def-clear path candidate sets. We first search for the preambles and 
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Figure 4 The test case generation procedure using the distributed analysis method 



the postambles that are context independent. Only one context independent 
preamble or postamble for each state is found out and used. If failing to find out 
any context independent component for a state, we search for all the context 
dependent components for the state and build the context dependent compo- 
nent candidate set for the state. Each element in the set is a candidate for a 
preamble or a postamble. Then, CS (Characteristic Sequences) of states in the 
model are derived in the same way as test component derivation. The context 
independent CS are generated in the first place and the context dependent CS 
candidate sets are generated for the state having no context independent CS. 
Then, we search for def-use pairs for data fiow test. A def-use pair is context 
independent if the edge of the de/has no predicate. Otherwise, the def-use pair 
is context dependent. 

After those basic test components are generated, main test cases for control 
and data fiow test are derived by direct assembling or simulation. In normal 
cases, generation of test cases for state identification is optional while test 
cases for transition identification is necessary. State identification verifies the 
uniqueness of CS, so it increases the fault coverage of a test suite(Anido and 
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Cavalli, 1995). For state identification, input sequences of all CS are fed to 
each state to check if generated output sequences of each CS are unique. To 
reduce the problem size, we can select (n)-state identification criterion. If there 
are some states having context dependent component candidate sets or CS 
candidate sets, we can pick up the elements fit for the other given components 
by simulation. Then, test cases satisfying transition identification criterion are 
generated. As we know, these test cases are for detection of transfer errors 
and output errors of transitions. The test case of a transition is composed 
of the preamble, the transition, CS and the postamble. If you can not find 
out a context independent element for any element, we can pick up the proper 
element in the relevant candidate set by simulation. You can increase the test 
coverage of the test suite by generating test cases satisfying p(n)-nh-transition 
identification criterion additionally. As shown in Figure 2 and 3, transition 
identification criterion covers any-uses criterion. Test coverage of any uses 
criterion is almost lowest among data selection criteria. Test cases for data 
flow test has been disregarded to a test suite designer for its big size. More 
test coverage for data flows, however, may be needed for more complete test. 
Technical advance may be able to pay the expense of data flow test. In any 
case, if additional test cases for data flow test are required, we can select one 
of the data selection criteria, find out the proper def-clear paths and generate 
the test cases by assembling or simulation. AZ/-de/ criterion or all-uses criterion 
will be a good selection for its efficiency, we think. 

We used the DFS (Depth-First Search) method as the search method in sim- 
ulation. The search method is explained in next section with other reduction 
techniques of problem size. The efficacy of this distributed analysis method is 
discussed in section 6 with the empirical results. 

5 PROBLEM SIZE REDUCTION TECHNIQUES 

We used three problem size reduction techniques in the proposed methodology: 
the DFS with termination conditions, the partial supplementation technique and 
the partitioning technique to reduce the complexity of simulation. 

Normally in reachability analysis, the BFS(Breadth First Search) method 
is used, because the reachability graph is infinite. In this paper, however, we 
used the DFS method because we need the reachability graph of a specific part 
rather than that of the whole specification. Because we have some information 
about the way to the target sequences, we can And out the executable path 
to the target sequences faster. We used termination conditions of simulation 
to prevent infinite simulation. Two conditions were used for termination of 
simulation: the characteristics of the minimized EEFSM and the satisfaction 
of the selected test coverage. The minimized EEFSM is generated by merging 
the homogeneous states having same data values. So if the homogeneous state 
having same data set as the already generated states are generated by simula- 
tion, the simulation is terminated. If all the sequences satisfying the selected 
criterion are found out, the simulation is also terminated. 
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We used the partial supplementation technique to reinforce the fault coverage 
of only a specific part of the specification. We can select some states and 
generate test cases satisfying (n)-state identification criterion for the states 
only. We can also select some input parameterized transitions and generate 
test cases satisfying p(n) -transition identification criterion for the transitions 
only. In the same way, we can select some variables and generate test cases 
satisfying higher level of criterion among data selection criteria for the variables 
only. 

The specification has several control variables. But some control variables 
may lie in a specific part in a functional group. The partitioning technique 
makes use of this feature and reduce the number of control variables partially 
by the functional partitioning. Each partition has, therefore, smaller control 
variable than the whole specification, but has full information about its control 
variables. If the values of the control variable of the partition change, a new 
state having the changed data of its control variables is created. For the control 
variables of other partitions but not of the present partition, each partition has 
the data set of the variables. If the values of one of the variables change which 
are not the control variables in the present partition, instead of creating a new 
state, only the changed value is added to the data set of the variable. Only 
after the execution path may go out to other partitions where the variables is 
the control variable, according to the elements of the data set, new states are 
created. This technique with the above termination conditions reduces the size 
of the generated EEFSM by simulation considerably. 

We did not use any optimization technique such as the RCP method addi- 
tionally to reduce the number of test cases. Because optimization techniques 
will blur the test purposes and decrease the test coverage of the generated test 
cases in most cases(Anido and Cavalli, 1995). 

6 EMPIRICAL RESULTS 

To show the efficacy of the proposed framework and methodology, we applied 
the methodology to the SSCOP (Service Specific Connection Oriented Proto- 
col) used in the B-ISDN AAL(ATM Adaptation Layer). This protocol is often 
chosen for conformance test because its SDL specification was standardized in 
ITU-T and its abstract test suite in TTCN was released in ATM FORUM. 
Besides, several test case generation tools such as TVEDA or SAMSTAG also 
generated abstract test suites of the protocol. 

For generation of test cases, we adopted DS (Distributed Single layer) method, 
because an upper interface to the lUT exists in the method, which make it possi- 
ble to generate desirable test cases with high test coverage. As the test coverage 
of a test suite, we selected both transition identification criterion and (6)-state 
identification criterion for control flow test and all-defs criterion mainly and 
all-uses criterion partially for data flow test. The partially selected criterion 
increases fault coverage of the specific part. For addition of test cases sat- 
isfying (6)-state identification criterion, we selected the state set, { SO(Idle), 
S2(Outgoing Connection Pending), S10(Data Transfer Ready), S7(Outgoing 
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Recovery Pending), S8(Recovery Response Pending), S4(Outgoing Disconnec- 
tion Pending) }. For partial addition of test cases satisfying all-uses criterion, 
we selected the data element set, { VT(S), VR(R) }. 

SSCOP has 10 states and more than two hundred edges. The state, SIO is 
for data transfer and the edges from/to the state are rather complex. The edges 
have cascaded predicates and inside recursions. We cut the edges into each seg- 
ment subedges. Thus we generated an EFSM model for the specification that 
has 10 states, 150 edges and 98 subedges. By model analysis, we generated 
the preamble of each state that is context independent and the context inde- 
pendent postamble of each state. We derived each context independent CS for 
7 states but for the states, S8, S9(Incoming Recovery Pending), and SIO, we 
generated context dependent CS candidate sets whose elements are 2, 3 and 26 
each. The SDL specification of SSCOP has 12 variables, 8 PDU parameters, 5 
SSCOP parameters, 7 signal parameters, 5 timers, 15 PDUs and 23 signals. We 
considered only variables and timers for data fiow test. The numbers of defs to 
constants/ de/5 of the variables, VT(PS), VT(A), VT(PA), VT(MS), VT(PD), 
VT(CC), VT(SQ), VR(H), VR(MR) and VR(SQ) are 17(10), 12(12), 11/11, 
21/21, 17/20, 20/24, 1/17, 18/18 and 19/19 each. The numbers of the pairs 
use to predicate or output/ def-use pairs of the variables, VT(S) and VR(R) are 
(10,32)/(11, 33) and (11,9)/(13,12) each. 

We used the partitioning technique to reduce the complexity of simulation. 
We separated the complex data transfer part around the state SIO and par- 
titioned it into five parts as the input. The number of the control variables 
for the whole specification are twelve or all the variables, but the numbers of 
control variables for six partitions are 2, 3, 3, 2, 2 and 5 each. This partitioning 
technique, therefore, could reduce the size of generated EEFSM effectively. 

We generated 72 test cases satisfying (6)-state identification criterion for the 
six states and 205 test cases satisfying transition identification criterion for all 
the edges and subedges for control fiow test. For data flow test we generated 
159 test cases satisfying a//-de/ criterion for the ten variables and 376 test cases 
satisfying all-uses criterion for the two variables. Because of not using any 
optimization technique, the number of the test cases for data flow test is rather 
large. 

7 RELATED WORKS AND EVALUATION 

A lot of researches has been made for automatic generation of test cases for 
both control and data flows (Chanson and Zhu, 1993; Kim, 1995; Ramalingom et 
a/., 1995; Bourhfir et a/., 1997). Those researches modeled a single module of a 
protocol to a single module EFSM and generated test cases satisfying transition 
identification criterion for control flow test and all-du-paths or all-uses criterion 
for data flow test. They used the techniques to give the executable values 
of input parameters like linear programming or CIUS( Context Independent 
Unique Sequences) for not considering executability of the sequences. However, 
the techniques are valid only in the assumptions that are too strong for the real 
protocols. The CIUS method is not always applicable because there are many 
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protocols that do not have the CIUS for all states like SSCOP. In addition, 
the protocols used for their experiments are too simple compared with real 
protocols and an EFSM model is too weak to model big and complex protocols 
such as SSCOP. 

TGV, TVEDA and SaMsTaG are automatic generation tools of test suite 
in TTCN(Doldi et al, 1996; Grabowsky et al, 1997). TGV, TVEDA V3 and 
SaMsTaG use simulation to search for test cases relevant to given test purposes. 
They generate a test suite satisfying only all-edges criterion. TGV uses feeds 
and filters to reduce the problem size. But because they exclude some messages 
and edges, they may not be able to find out test cases relevant to a certain test 
purpose. TVEDA V2 uses the syntactic techniques with some constraints and 
generates test purposes automatically by heuristic methods. But constraint 
parts of a test suite generated by TVEDA V2 are incomplete and require manual 
completions. TVEDA V3 overcame this weakness by using simulation but it 
still ignores test suite having more test coverage. SaMsTaG needs test purposes 
in form of MSCs, from which test cases are generated by simulation. But it fails 
to find out test cases for a considerable amount of test purposes. Developers of 
these tools are now interested in completing the tools rather than in generating 
more powerful test suites. 

ATM Forum released an abstract test suite in September 1996(ATM FO- 
RUM, 1996). The test suite uses the verifying sequence for each state and 
attaches it to the transition relevant to each test purpose. The test suite, 
therefore, satisfies almost transition identification criterion. But in the test 
suite, a considerable amount of test cases are omitted including the ones for 
transitions starting from four states. And the test suite uses the same verifying 
sequence for each state, which may make some test cases not executable. 

The proposed framework and methodology consider those weakness men- 
tioned above. They are interested in test cases having higher test coverage as 
well as the generation of executable test cases for real protocols by using both 
model analysis and simulation. 

8 CONCLUSIONS AND FUTURE WORKS 

In this paper, we proposed new framework and methodology for automatic test 
case generation for a real protocol. The distributed analysis technique, the core 
of the proposed framework, makes use of the advantages of model analysis used 
in theoretical methods and simulation used in practical methods. We can se- 
lect one of the redefined test coverage criteria for generating a test suite having 
higher test coverage. State space explosion by simulation can be reduced by the 
depth first search with termination conditions and the partitioning technique. 
We generated the test cases of SSCOP satisfying (6) -state identification crite- 
rion and transition identification criterion for control fiow test and satisfying 
all-defs criterion and all-uses criterion for data fiow test. The test cases were 
generated by a simple tool with a simple simulator partially and by manual 
efforts partially. 
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We are planning to develop a complete tool where the proposed framework 

and methodology are implemented. Besides, we are studying a method to cope 

with communicating multiple module protocols and time-relevant protocols for 

multimedia communication. 
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Quality of Service in Integrated Networks 

Prof. PaulJ Kuehn, University of Stuttgart, Germany 

Abstract 

Communication Networks migrate towards an infrastructure, which 
ischaracterized by seamless interoperation of heterogeneous 
subnetworks with different protocol architectures, network technologies, 
and services. The user will not be aware of this heterogeneity, but relies 
on a secure, reliable and efficient operation supporting his applications. 
To provide such a quality of service, communication networks have to 
meet stringent quality requirements with respect to 

- functions and features 

- availability and reliability 

- security 

- real time performance 

- speed and throughput. 

For the individual requirements particular methodologies have been 
developed, such as specification, verification, implementation, modeling, 
simulation and testing techniques. These techniques reflect the particular 
needs and are only partially interrelated. Often, they are applied (if at 
all) sequentially and independently. The extended functionalities of 
future communication network infrastructures indicate a more integrated 
approach. 

In the talk we will define the requirements of enhanced methodologies. 
Some examples will be given to elucidate the needs such as integrated 
function and performance testing of switching systems or feature 
interaction. FDTs may be rather useful but they are limited to closed 
subsystems. Integrated methodologies have to be supported by 
standardization, built-in capabilities and tools. 
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Enumeration protocol in Estelle: 
an exercise in stepwise development 
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Abstract 

The paper sketches a design process that starts with a mathematical solution of 
the enumeration problem and ends up with a distributed, efficient, and 
successfully terminating protocol in the specification language Estelle. The 
subsequent versions of the protocol are obtained from their predecessors by well 
controlled and small modifications that (almost) obviously preserve 
correctness. The target, successful (successful with arbitrarily high probability) 
solution allows forgetting theoretical "impossibility results", which prove non- 
existence of such successful distributed solutions for some classes of networks. 

Keywords 

Distributed algorithms. Formal Specification, Verification, FDT Estelle. 



1 INTRODUCTION 

The enumeration problem is one of a number of similar problems (election of a 
leader, mutual exclusion, termination, etc.) that have been studied because of 
their importance for distributed systems and networks, i.e., systems composed 
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of a number of independent processes running in parallel and communicating 
by messages. A solution to the problem (an algorithm) is considered distributed 
if the processes run the same algorithm, no process is privileged, and their 
computation decisions are solely based on local information and information 
gained through messages coming from neighbour processes. A distributed 
algorithm in the above sense is called protocol. 

In the enumeration problem, networks of processes are abstracted by 
graphs that are; finite, connected, and without self-loops. Nodes correspond to 
processes and the graph relation represents the communication links between 
them. The enumeration problem consists in finding a distributed algorithm 
(protocol) that terminates with all processes (nodes) of a network (graph) 
properly enumerated, i.e., each process of an N-process network gets a unique 
label from the set { 1, 2, ... , N}. 

It is known that for some graphs (ambiguous graphs) there is no distributed 
enumeration algorithm that always terminates successfully (so called, 
impossibility results, e.g., in (Litovsky at al., 1993)). Several solutions have 
been proposed that worked for specific classes of graphs (like, e.g., rings). In 
(Mazurkiewicz, 1997), an elegant protocol, that works for all unambiguous 
graphs, is presented and proved correct. The solution is kept at a high-level of 
abstraction to reduce the interference of particular realization choices to a 
necessary minimum. 

The aim of this work has been to implement the Mazurkiewicz protocol, 
i.e., the protocol from (Mazurkiewicz, 1997), in the specification language 
Estelle (ISO, 1989) and to experiment with Estelle supporting tools EOT 
(Estelle Development Toolset, (Budkowski, 1992)). Also, the work seemed a 
good case study to show that such an implementation can be obtained in a way 
that preserves correctness of the original solution proved at a higher, 
mathematical level. This occurred feasible, but it also occurred that trying to 
translate, as close as possible, the main protocol ideas from (Mazurkiewicz, 
1997) into environment where sharing variables is not possible (a direct 
availability of values of internal variables of processes in the neighbourhood of 
a given process, is one of the simplifying assumptions in (Mazurkiewicz, 
1997)), leads to an inefficient and clumsy solution. Moreover, not all properties 
of this solution were exactly the same as in the original. The obtained protocol 
is discussed in Sec. 2 with illustrative extracts from its Estelle specification 
(EPl: Enumeration Protocol 1). 

Being not satisfied with the obtained Estelle specification, a modification 
of the original protocol has been proposed that resulted in a solution which is 
both economic and has exactly all properties of the original. The solution (EP2) 
is analyzed and described in Section 3. The way it is obtained from EPl shows 
again that its correctness can be deduced directly from this predecessor version, 
hence, indirectly from its mathematical original. In the following section the 
notion of ambiguity of a graph is briefly discussed in order to explain non- 
existence of an (always successful) distributed enumeration algorithm for 
ambiguous graphs. A very simple extension to EP2 (EP3) makes the protocol 
"always" successfiil, i.e., even for ambiguous graphs. The word always is 
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appropriate since success can be achieved with arbitrary high probability. 
Again, correctness of EP3 protocol follows directly from the correctness of 
EP2. A frill Estelle specification of EPl, EP2 and EPS can be found in 
(Dembinski, 1996). The last "probabilistic" solution led the author to a radical 
reformulation of the protocol into a randomized one, but this reformulation is 
the subject of a separate paper (Dembinski, 1998). 



2 MAZURKIEWICZ ALGORITHM AND ITS IMPLEMENTATION BY A 
NETWORK OF IDENTICAL COMMUNICATING PROCESSES. 

The enumeration protocol in (Mazurkiewicz, 1997) is assumed to be performed 
by a network of sequential processes, each one for a node of the graph to be 
enumerated (named). Similarly as for the graph itself, we use the term 
neighbour {neighbourhood) of a process to mean another process (all 
processes) representing a node (all nodes) directly in the graph relation with 
the node of the process. Each process has its main local variables (we are using 
slightly different notation than in (Mazurkiewicz, 1997)): 

ownjiame - storing the current name (number) assigned to the process 
(initially all processes have no names, i.e., own_name = 0), 
known_names - storing a set of names (numbers assigned to neighbour 
processes and currently known to the process; initially, 
knownjmmes = 0), 

knowledge - storing a set of pairs (name, set_of_names) representing the 
current knowledge of names of other processes in the network 
and their known_names at the time the knowledge was 
acquired (initially, knowledge = 0) 

In the informal description of the algorithm in (Mazurkiewicz, 1997), the 
author explains the local behavior of each graph node by means of message 
exchange between neighbour nodes. In fact, such an exchange of messages is 
necessary if we really think of the algorithm realized in a network of sequential 
processes. However, in (Mazurkiewicz, 1997), for the sake of simplicity of the 
correctness proof of the enumeration protocol, an indivisible, atomic 
computation step of each node is realized as if each process had a direct 
read/write access to all local variables of its neighbourhood. The atomic step 
(identical for each process) repeated until the terminationjcondition is satisfied 
can be described, in Pascal-like terms, as follows: 

repeat 

if knowledge_injhe_neighbourhoodJs_notjhe_same then unify; 
if renaming jcondition then rename 
until terminationjcondition 
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Without going into details of the conditions and procedures, it is worth to point 
out that the condition knowledge Jn_the_neighbourhood_is_notjhe_same and 
the procedures unify and rename use and change values of local variables of the 
neighbourhood processes. That is why the whole step is kept atomic. With such 
an approach elegant proofs are provided for the following results: 

1. The protocol always terminates. If graph is not ambiguous (see Section 4) 
the protocol terminates with its nodes properly (or successfully) enumerated 
{successful termination). If graph is ambiguous the protocol may terminate in 
a state in which no process can continue {unsuccessful termination) but the 
graph nodes are not properly enumerated (see example in Section 4). 

2. The protocol may reach any given proper enumeration for an arbitrary 
finite and connected graph, i.e., even for ambiguous graphs the protocol may 
reach a proper enumeration. 

3. If the protocol terminates successfully, then each node knows about this 
termination. Moreover, each node has enough information to reconstruct the 
whole graph (i.e., the protocol solves the graph recognition problem). 

4. The protocol solves the election problem (see, e.g. (Bouge, 1988)) for all 
unambiguous graphs (it chooses a leader-node and any node can be chosen as 
a leader). 

5. The protocol is distributed in that, in principle, processes that do not have 
a common neighbour can run in parallel (the parallelism is modelled by 
interleaving). Otherwise, their actions must be mutually excluded. 

The proofs in (Mazurkiewicz, 1997) follow from a key invariant property of the 
above algorithm. The property says that each computation step preserves so 
called connectivity of the graph enumeration. Assume that a graph has N 
nodes. An enumeration is a function from the graph nodes V into the set {1, 2, 
..., \V\}. An enumeration /is called connected if, for every jc in V such that f(x) 
= n+7, there is y in V with/(jc) = n. The proof of invariant goes by induction. 
Of course, if nodes have no names (all names are set to 0), then the property 
holds. Each step may rename a node and therefore define a new enumeration 
which is increasing its maximal value. The first one is obviously connected (it 
gives 1 as a name to exactly one node). It is sufficient then to prove that a 
computation step cannot destroy this connectivity. Finally, if a node gets I VI as 
its name, then by the connectivity argument, a proper enumeration is achieved 
and the algorithm terminates with each node having knowledge about the 
whole graph. To complete the proof it should be added that, for an 
unambiguous graph and for any non-terminal state, eventually a node is 
renamed (i.e., a new enumeration function is eventually created). 
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Our first goal is to specify a distributed version of the protocol, i.e., such in 
which local variables of a process cannot be accessed by another one. Exchange 
of messages can be the only way of knowing their values. 

Below, we describe a distributed solution (EPl) in terms of a (well known) 
model assuming that each process is described by a finite set of guarded 
commands. A guard is a boolean condition over a space of the process internal 
states and the contents of its (unbounded) communication mailbox storing 
incoming messages. A command defines an action that may change an internal 
state, may remove some messages from the process's mailbox, and it may send 
messages to some other processes connected to the given process. A message 
sent to a process is (immediately) appended to its mailbox. The action defined 
by a process command is assumed indivisible (or atomic). The communication 
is asynchronous in that a process may always send a message or, in other 
words, operations of sending and receiving messages are not synchronized. A 
process, in each of the computation steps, performs one of the commands from 
among those for which their guards evaluate to true. The behavior of a network 
of processes is described by interleaved sequences of processes' actions. 

Specifying the Mazurkiewicz protocol in the above model is fairly 
straightforward if one is not going into details. That is what we are trying to do 
in this paper: an informal description completed with some corresponding 
parts in Estelle to illustrate how close an Estelle specification can mimic the 
colloquial (though precise) language. The basic idea in this first distributed 
solution is to replace the direct access to the values of local variables of 
neighbour processes by the exchange of messages that include these values. 

Enumeration Protocol (solution) 1 (EPl) 

In the description below we refer to the following elements: 

- messages: request - asking for actual contents of local variables of 
neighbour processes, 

response - responding to a request and containing the 
requested information (values of own_name, 
known_names and knowledge), 

new_knowledge - a message containing, for each neighbour, a 
newly created value of its known_names and a 
unified knowledge, for all of them; one such 
message is transmitted to each of the neighbours of 
the process that previously requested information 
from them. 

Estelle definitions of a network node and some types of basic data stored 
in nodes and exchanged between them: 



{ A specification of the architecture of enumeration protocol EPl is 
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given, for a graph of size given by 'graph_size' constant and generated 
by 'graph_creation' procedure in 'initialize' part of the specification. 

A node of the network (graph) is defined by the module header 'node' 
and the module body ‘node_body’with its input and output ports 
specified by vectors of length 'graph_size' of interaction points (ip). 
Ports of the instances of nodes are connected in part 'initialize' 
of the specification, by communication channels of type 'link(Rl, R2)' 
and according to the edge structure of the graph. Messages circulate 
through channels. Allowed messages are defined within channel 'link'. 
Sets of names ('L_set') are defined as sets of integers from the set 
'V = 1 .. graph_size', while pairs composed of a name and a set of 
names have the record 'K_el' definition. 

Knowledge is represented by an array of 'max' length. Its actual 
contents are reduced to 'K_el' elements that are not equal to 
(max, empty). This not very elegant solution is chosen because of the 
Estelle restriction that does not tolerate dynamic arrays and forbids 
pointers in messages. 

The 'systemactivity' attribute of the specification means that behavioral 
semantics are given by interleaving. } 

specification EPl systemactivity; 
default common queue; 
const 

graph_size = any integer; 

max = any integer; (greater than graph_size, eg. graph_size''2} 
type 

zero_one = 0..1; 

V = l..graph_size; 

neighbour_representation = arrayfV] of zero_one; 
graph_representation = array[V] of neighbour_representation; 

L_set = set of 0..graph_size; 

K_el = record 
ng : integer; 
known: L_set; 
end; 

K_set = array[l ..max] of K_el; 
channel link(Rl,R2); 
by R1,R2: request(ad:V); 

new_knowledge(l:L_set; k:K_set); 
response(l:L_set; k:K_set; n:integer) ; 
module node activity (ngh: neighbour_representation; nad:V) ; 
ip s_neighbour: array [V] of link(Rl); 

r_neighbour: array[V] of link(R2); 
end; (node header] 
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- local node variables own_name, known_names, and knowledge as 
described above, 

- local node control states idle, wait_new_knowledge, wait_response and 
termination. 

Estelle counterparts: 
state 

idle, wait_response, wait_new_knowledge, termination; 
var 

known_names : L_set; 
knowledge : K_set; 
own_name: integer; 

- termination jcondition that evaluates to true, in a process, if its local 
variable knowledge contains an element named by the number that equals 
the size of the enumerated graph. 

Estelle counterpart: 

exist i:l..max suchthat (knowledge[i].ng=graph_size) 

- renaming ^condition that evaluates to true, in a process, either when the 
node is nameless (own_name=0) or knowledge contains an element 
named the same as the node (i.e., the element's name equals own_name) 
but has a stronger (see Section 4) set of names known to it, 

- rename procedure which assigns a new name to the node represented by 
the process executing the procedure; the new name is greater by 1 than all 
names known to neighbours; the procedure also prepares a new, unified 
knowledge for all neighbours and new nown_names for each of them; the 
new values are then communicated to neighbours. 

In Estelle, both the renamingjcondition and the rename procedure occur 
within transitions' bodies and use simple auxiliary functions. We omit 
them here, since their implementation has nothing specific (they are 
simple Pascal procedures). 

A process initially has its mailbox empty, its local variables initialized as 
described above, and its local control state idle. The meaning of the guarded 
commands of each process is characterized as follows: 

• (sending requests) 

The process broadcasts request to all its neighbours (asking for actual values 
of their local variables) and then waits for their responses changing its local 
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state to waitjresponse, provided: its mailbox is empty, the 

terminationjcondition is false and its control state is idle. 

Estelle counterpart: 

from idle to wait_response 
name sending_requests: 
begin 
all i: V do 

if ngh[i]=l then output s_neighbour[i].request(myad); 
end; 

• (responding to requests) 

The process receiving the request message from a neighbour (the message is 
in its mailbox) responses to the requesting process sending the current values 
of its local variables (message response) provided its control state is 
termination or it is idle and the terminationjcondition is false; in the first 
case the control state remains the same, while in the second it changes to 
waitj%ewJcnowledge\ in any case the request message is removed from the 
mailbox. 

Estelle counterpart: 

from idle to wait_new_knowledge 
any i: V do 
priority low 

when r_neighbour[i].request(ad) 
name response_to_request_i: 
begin 

output s_neighbour[ad].response(known_names, knowledge, 
own_name); requesting :=ad 

end; 

{ Transition priorities plus common queue organization give a possibility of 
excluding the non-determinism between transitions. It is explicity excluded 
in the model description by guards that are impossible to express in Estelle, 
e.g., emptiness of a queue is not expressible. It is also worth to note that, in 
Estelle, a message received and served by a transition is, by definition, 
removed from the appropriate queue. This is not the case in the original 
asynchronous model operating on a mailbox, hence it must be repeated 
when needed} 

• (receiving responses, creating and distributing knowledge) 

If response messages arrived to the process mailbox from all neighbours 
while the process's control state is wait_response, then the process checks the 
renaming jcondition and if it is satisfied, it performs the rename procedure; 
independently of the condition value the process unifies its current knowledge 
with that included in response messages and then this new knowledge, with 
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possibly new knownjiames, for each neighbour (message new_knowledge), 
are transmitted back to neighbour processes; finally the process removes all 
response messages from the mailbox and changes its control state to idle. 

Estelle counterpart: 

from wait__response to idle 

provided count=ngh_number {i.e., all responces already arrived } 
name creating_and_distributing_knowledge: 
begin 
count := 0; 

if (own_name=0) or (exist j:L. max suchthat 

rename_cond(knowledge|j], known_names, own_name)) 
then 
begin 

maxname(maxn); new_know(maxn); own_name:=maxn+l 
end; 

all i:V do if ngh[i]=l then add(resp_k[i], knowledge); 
all i:V do if ngh[i]=l then {i.e., if i is a neighbour} 
output s_neighbour[i].new_knowledge(resp_l[i], knowledge); 
end; 

• (receiving new knowledge) 

The process receiving new_knowledge message from a neighbour (the 
message is in its mailbox) either ignores it, if it was already in the 
termination state (and stays in the same state) or, being in the control state 
wait_new_knowledge, it actualizes its local variables with the received values 
and changes its control state to idle; then, as always, it removes the 
new_knowledge message from the mailbox. 

Estelle counterpart: 

from termination to termination 
any i: V do 

when r_neighbour[i] .new_knowledge 
name ignoring: 
begin end; 

from wait_new_knowledge to idle 

when r_neighbour[requesting].new_knowledge(l, k) 
name absorbing_new_knowledge: 
begin 

known_names := 1; knowledge := k; requesting := 0 
end; 

• (terminating) 

The process passes to the control state termination as soon as its control state 
is idle and the termination_condition is satisfied. 
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Estelle counterpart: 

from idle to termination 

provided (exist i:l..max suchthat (knowledge[i].ng=graph_size)) 
priority highest 
name terminal: 
begin end; 

It seems completely obvious that connectivity (of enumerations determined by 
values of own_names variables) is preserved by anyone of the above transitions. 
Hence, (variants of) properties 1-5 could be proved by similar techniques as in 
(Mazurkiewicz, 1997) (of course, with all changes resulting from the change of 
model and differences between the chosen asynchronous model and this of 
Estelle). However, it is worth to point out a slight difference in properties 
which does exist. To prove the termination property of EPl a global fairness in 
computation is needed. Without it, infinite and useless sequences of requests 
and responses are possible even if graph is not ambiguous. In the Mazurkiewicz 
protocol checking the if conditions do not require any actions, hence no useless 
actions are initiated. In case of an ambiguous graph such endless computations 
repeating exchange of information without further progress in enumeration are 
reflecting the fact that locally one cannot recognize the ambiguity. The global 
termination is locally known to all processes since a process that achieves its 
termination control state knows that eventually all other will end up in this 
state. 



3 ALWAYS TERMINATING AND ECONOMIC PROTOCOL 

The distributed enumeration protocol that is described in the previous section 
(and implemented in Estelle) has some flows that are inherited from its 
prototype in (Mazurkiewicz, 1997). 

First of all, the amount of information that is exchanged between 
processes. For instance, the knowledge value is always included in a response 
message. The inclusion occurs because the description tries to follow, in an 
exact way, the original solution. The question is, however, whether it is 
necessary. If the answer was negative, then all protocol messages can be 
bounded by the graph size and not by the square of this value as it is in EPl. 

Second, one would like a distributed protocol that always terminates, either 
successfully or not, as it is the case in the original. Moreover, this termination 
condition should not be dependent upon a fairness property which in its nature 
is of a global character. Recall, that this fairness property is hidden in the 
original solution by the assumption that makes value of the enabling condition 
knowledge Jinjhe_neighbourhood_is_notjthe_same instantaneously "known" 
to the processes without any explicit evaluation procedure. 

The protocol specified below (EP2) satisfies the above postulates and 
preserves all properties of the original solution. 
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Enumeration Protocol (solution) 2 (EP2) 

All initial assumptions of EPl remain the same for EP2 with the following 
exceptions and/or additions: 

- two messages are added to the set of possible exchange messages (and the 
contents of the remaining messages are not exactly the same as before): 

done - the message, spread over the network, causes a global and 
successful termination of the protocol, 
transjcnowledge - the message transmits a name and a set of names 

(as also do now new_knowledge and response messages) and serves 
to ca newly created name of a process-node, together 
with names known to it, 

- termination_condition reduces now to the equality: own_name^graph_size, 

- rename procedure is reduced to produce a new name of a process. 

Of course, there are many other details that are different in both solutions, i.e., 
EPl and EP2, at the level of Estelle specification. Below we present the 
specification of types and messages of EP2 to enable the reader to grasp these 
minor differences. Anyway, the essential difference is in the size of messages 
(values of all neighbour knowledge variables are not transmitted) and the way 
new knowledge is disseminated. These differences in both solutions can be 
captured examining respective guarded commands of each node-processes. 
That is why we present guarded commands of EP2 in the style used for EPl, 
but Estelle transitions of EP2 are not presented here. 

L_set = set of 0..graph_size; 

K_el = record 

ng : integer; 
known: L_set; 
end; 

K_set = ^KK_el; 

KK_el = record 

kel: K_el; 
next: K_set 
end; 

channel link(Rl,R2); 
by R1,R2: done; 

request(ad:V); 
new_knowledge(el: K_el); 
response(el: K_el); 

trans_knowledge(ad:integer; el: K_el); 
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Guarded commands for EP2: (we try to keep similar wording as in EPl to 

facilitate a comparison): 

• (sending requests) 

The process broadcasts request to all its neighbours (asking for actual values 
of their local variables) and then waits for their responses changing its local 
state to waitjresponse, provided: its mailbox is empty, the 

terminationjcondition is false, the renamingjcondition is true, and its 
control state is idle. 

• (responding to requests) 

The process receiving request from a neighbour (the request message is in 
its mailbox) responses to the requesting process sending the current values of 
its local variables (message response which now includes the values of 
own_namQ and knownjnames only) provided its control state is idle and the 
terminationjcondition is false', the new control state is wait_new_knowledge 
and the request message is removed from the mailbox. 

• (receiving responses, creating and distributing knowledge) 

If response messages arrived to the process mailbox from all neighbours 
while it is in wait_response control state, then the process performs the 
rename procedure and its new ownjiame together with its current value of 
knownjiames is broadcast to neighbour processes (newjcnowledge message); 
finally the process removes all response messages from the mailbox and 
changes its control state to idle. 

• (receiving new knowledge) 

The process, being in the control state waitjiewjcnowledge and receiving 
newjcnowledge message (the message is in its mailbox) from a neighbour 
previously requesting the values of the process’s local variables, actualizes its 
local variables knowledge and knownjiames with the received values, 
changes to idle, removes the newjcnowledge message from the mailbox and 
broadcasts two transjcnowledge messages: one with the values as they were 
received in the newjcnowledge and the second one that includes its own 
values ownjiame and actualised (according to the newjcnowledge) 
knownjiames (of course, the first transjcnowledge message is not returned to 
the process sending the newjcnowledge information). 

• (transit of knowledge) 

The process, being in any control state and receiving a transjcnowledge 
message, checks whether the transiting knowledge is or is not known to it 
(the pair of values is or is not included in its knowledge) and if it is not, then 
it actualizes its own variable knowledge and retransmits the transjcnowledge 
message to all its neighbours but the sending one; otherwise, i.e., when it 
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already knows the transiting knowledge, it ignores the received information; 
in both cases the message is removed from the mailbox. 

• (terminating) 

The process passes to the control state termination if only it was in the 
control state idle and either 

the terminationjcondition was satisfied or the message done is in its mailbox; 
in both cases the process sends then the message done to all its neighbours. 

Essential change in EP2 with respect to EPl is in that transjcnowledge 
messages are introduced and treated. In EPl, new knowledge was acquired by 
repeated requests to neighbours whether it was necessary or not. In EP2, new 
knowledge is spread over the network only if it is really new. An information 
included in a transjnessage that is already known to a process is not 
retransmitted. That way a new information eventually reaches all processes but 
also its retransmission eventually ends up, i.e., there are no useless and endless 
loops caused by retransmissions. A transjnessage is only created if the 
enumeration is successful. In that situation no other process but the terminating 
one may proceed. All other processes are in their idling states waiting for a 
message that can trigger an action. If done message arrives, it is retransmitted 
only once and the process terminates definitely. Therefore, eventually all 
processes terminate. Anyway, EP2 always terminates, as did the original 
protocol in (Mazurkiewicz, 1997), either successfully enumerating the graph 
(all processes are in their termination control state) or without a successful 
enumeration, with all processes waiting forever in their idle state. 

Again, it seems obvious, that connectivity invariant holds for EP2. The 
proof of it, provided we've already proved EPl, is by checking whether the 
invariant is preserved by new transitions. The point is that those changes we 
are introducing result in better protocol but do not destroy the essence of our 
correctness proof 



4 IMPOSSIBILITY RESULTS AND ALWAYS SUCCESSFUL PROTOCOL 

The reason why a distributed enumeration protocol can fail, i.e., why it can end 
up without a proper enumeration of a graph, is due to some graph-theoretic 
property of the graph itself This property establishes a class of graphs 
(networks) for which so called impossibility results hold (see, e.g., (Litovsky at 
af, 1993)). This class of ambiguous graphs is defined by a notion of graph 
folding which is a graph morphism such that its restriction to any graph node 
and its neighbourhood is bijective. Recall, that a graph morphism is a mapping 
from the set of nodes of the graph into the set of nodes of another graph 
preserving graph relation (graph edges). Now, a graph is ambiguous if there 
exists a folding (from the graph nodes onto the nodes of another graph) that is 
not an isomorphism. 
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A nice characterization of the class through the notion of graph enumeration 
(labelling) is given and exploited in (Mazurkiewicz, 1997). Let G = (V, /?) be a 
graph. Denote by N(x) the set of all neighbours of the node x in V. Recall, that 
any function/.* V •> {1, 2, , \V\} is called enumeration of the graph G (the 

enumeration /is proper ox successful, iff(V) = fl, 2, ... , \V\}). Enumeration/ 
is called locally unique, if for each x,y,z€V such ihatfiy) =f(z)y we have: 

a. ify,ze N(x), then y = z 
h.f(N(y)) =mz)h 

Now, a proposition from (Mazurkiewicz, 1997) says that graph G = (V, R) is 
ambiguous if and only if there exists a locally unique and not proper 
enumeration of G. 

In Fig. 4.1. an example of an ambiguous 6-node graph is given. A folding 
into a 3-node graph is depicted (dotted lines) together with a locally unique 
node enumeration of the bigger graph that corresponds to the folding. Both 
prove the ambiguity of the graph. 



1 





It is an easy exercise to get this (unsuccessful) enumeration using commands of 
the algorithm EPl or EP2 in such a way that the enumeration proceeds as 
follows: 1, 1, 2, 2, 3, 3. It is then clear that once the above enumeration was 
achieved there is no hope for a successful termination. In case of EPl, only 
requests are possible (sending request command) but the responses are always 
the same, while EP2 terminates (deadlocks) in a state in which no process can 
continue. 

The impossibility results explain that a process (node) cannot locally 
distinguish itself from another one that looks exactly the same in terms of 
attributes describing the process (node) itself and its knowledge about all 
neighbours. In terms of the protocol constructs, this impossibility is reflected in 
the formulation of the renamingjcondition. If the attributes are equal, the 
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renaming jcondition xcmmm false and no renaming can occur. This is exactly 
what happens, for the example in Fig.4.1. in the situation when the given 
enumeration was achieved. Existence of a linear order between information 
characterizing processes (nodes) of the same name is absolutely necessary to 
start renaming and to prevent the situation when all of them start their 
renaming procedure in parallel. At least one of the processes should maintain 
the current name to hope for a successful enumeration. In (Mazurkiewicz, 
1997) this order, used in the renaming jcondition, is of lexicographical type 
between the set of names known to nodes. 

In view of the impossibility results, it seems hopeless to think of an always 
successful protocol. It is true in absolute terms. However, any computation has 
it own dynamics (ordered history) independent of the problem that is being 
solved. It may be used to add order to elements that otherwise are identical. 

Imagine that every new name created for a process (node), is "stamped" 
with a value from an ordered set of values (e.g., integers) and that the 
probability of the same "stamps" to the same name is arbitrary small. Nodes 
that are equal in previous sense become now ordered by their "stamps". A good 
random number generator in each node gives a sufficient practical solution for 
generating of "stamps". This is the whole idea of an enumeration protocol that 
terminates successftilly with arbitrary high probability. Hence "always " 
terminating in probabilistic terminology. By a slight modification of EP2 we 
get always successfully terminating enumeration protocol EP3. Its Estelle 
specification consists in a trivial adaptation of internal, primitive procedures of 
EP2. 

Repeating the exercise performed previously with EP2 for the example in 
Fig.4.1, will show that with the enumeration given in this figure and achieved 
by the protocol EP3 there is a continuation since we have assumed, in the 
protocol, that stamps in such situations are always different. Therefore, there is 
always a node (process) for which the renaming _condition is satisfied. 
Otherwise, EP3 behaves exactly as EP2, hence all properties satisfied for EP2 
are valid for EP3 as well. 



5 CONCLUSIONS 

We have studied the enumeration protocol given in (Mazurkiewicz, 1997) and 
provided a version (EPl) of it that does not use shared variables but only 
exchanges information by messages. This protocol is then implemented 
(specified) in the protocol specification language Estelle. Atomicity of actions 
in the new protocol is of smaller "granularity". An improved version (EP2) was 
then proposed which is economic in message exchange and does not assume a 
computation fairness implicitly present in the original solution and explicitly in 
EPl. This new version has exactly the same properties as the original one and 
solves also such problems as leader election and graph recognition. 

A discussion on the source of non-existence of distributed enumeration 
algorithm for ambiguous graphs, shows its "static" character, i.e., it refers. 
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roughly speaking, to impossibility of distinguishing, by local means, two 
graphs of different size but locally isomorphic (one graph can be "fold" into 
another). In any enumeration algorithm, this property translates into a 
possibility of reaching, from the initial state, a state in which all nodes 
(processes) are enumerated, but there are nodes that together with their 
neighbourhood are isomorphic not only with respect to the graph relation but 
also with respect to achieved enumeration. Such nodes cannot be distinguished, 
by local means, hence the enumeration procedure deadlocks with the graph not 
properly enumerated. However, the execution history can make the two nodes 
distinct even in this statically ambiguous situation. It is enough to "stamp" 
every newly produced name by a randomly drawn number. This simple idea 
has been implemented to obtain, in Estelle, a distributed enumeration 
algorithm that always successfully terminates, if the word always is understood 
in a probabilistic sense, i.e., the success can be assured with arbitrary high 
probability. The algorithm, EP3, is a simple extention of EP2 described earlier. 

The paper describes an exercise (case study) of a protocol design in Estelle 
starting from very high level, mathematical specification and ending up with 
its improved and executable prototype. It shows a starting, mathematical 
solution makes correctness proof much easier though the solution is neither 
efficient nor immediately executable. Then, in small steps one can obtain an 
improved version of the protocol that can be almost directly mapped into such a 
specification language as Estelle. The gain in such design process is that the 
final result is correct by virtue of the original proof for a mathematical 
formulation and correctness preserving development steps. Protocols EPl, EP2 
and EP3 are all results of such steps. 
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Abstract 

Hypermedia authoring tools usually suffer from a lack of 
validation capabilities that would make them capable of checking 
a document against temporal inconsistencies. The document 
design method proposed in the paper is meant to overcome this 
problem. The starting point is a document description provided in 
a high-level modeling technique featuring hypermedia basic 
concepts such as nodes (including composite nodes), anchors and 
links. The high-level document is then automatically translated 
into a RT- LOTOS formal specification on which classical 
reachability analysis techniques are applied, making it possible to 
check the temporal consistency of the document structure. A 
simple example is used along the text to illustrate the proposed 
approach. 



1. Introduction 

A fundamental problem in hypermedia document design is to characterize the 
temporal structure of such type of document. The temporal structure can be expressed 
by a conjunction of synchronization constraints that partly depend on user interactions 
(hence, the hypermedia character of the document). The quality of the document 
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presentation heavily relies on the global consistency of these synchronization 
constraints. 

So far, few work has been done on the identification and analysis of consistency 
properties for hypermedia documents (Buchanan, 1993a) (Courtiat, 1996) (Lakayda, 
1995). Main reasons are twofold: 

• Many models do not have any formal background to support automated proofs of 
consistency properties. 

• The importance of these properties has often been minimized, particularly 
because they are sometimes obvious on models with a limited expression power 
(like the timeline model (Blakowski, 1996) largely used in first generation 
commercial authoring tools). 

Hypermedia documents have been a reality for many years, but their current and 
already important deployment (like WEB pages and CD-ROMs) masks several 
limitations to be dealt with in the products of the next generation. Examples of 
limitations include the structure essentially static of the documents, and poor semantic 
models for expressing temporal synchronization, etc. 

Increasing dynamism in documents together with the use of more expressive 
models may result in a non-consistent temporal structure (Blakowski, 1996). Hence 
the need for improving the design process with a technique able to check the 
document temporal consistency. Early results on temporal consistency for hypermedia 
documents have been reported in (Courtiat, 1996), based on a new temporal 
synchronization model. That approach was however a not general proposal since the 
synchronization model was directly re-engineered from the underlying formalism, 
namely RT-LOTOS (Courtiat, 1995), a temporal extension of LOTOS. The high level 
model used in (Courtiat, 1996), and consequently the hypermedia document design 
approach, featured three major weaknesses: 

• The model was specific. 

• It did not handle completely the link concept, which is classical in hypermedia 
systems. 

• It did not distinguish a node type from a node instance; this was considered as the 
major limitation, since it was not easy to re-use part of a document (a node) in the 
design of another document. 

An enhanced approach is discussed in this paper. It overcomes the previous 
limitations and generalizes the concept of temporal consistency. The main 
contribution is the definition of an hypermedia design method which includes an 
automatic translation from a high-level hypermedia authoring model into a RT- 
LOTOS specification; this authoring model relies on those objects that are usually 
found in hypermedia document specifications, namely nodes (including composite 
nodes), anchors and links. This design method is applied here to the NCM authoring 
model (Casanova, 1991), and it is currently being implemented within the HyperProp 
Authoring System (Soares, 1995). 

The paper is organized as follows. Section 2 introduces the high level authoring 
model adopted in this work. Section 3 describes the translation procedure from the 
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authoring model to the RT-LOTOS FDT. Section 4 surveys RT-LOTOS verification 
techniques, with their RTL tool support, and shows how to apply them to prove 
hypermedia document consistency properties by reachability analysis. This section 
also illustrates some verification results that have been obtained on the running 
example used throughout the paper. Some conclusions are finally given in Section 5. 



2. Modeling hypermedia documents with temporai 
constraints 

2. 1. Hypermedia authoring systems 

Hypermedia authoring systems make it possible to integrate different media types, 
and to define temporal and spatial^ constraints among the document components. 
They offer well suited capabilities for structured document design, including 
navigation control and presentation monitoring. An authoring tool must be easy to use 
and sufficiently expressive in order to not impose a cognitive overhead to the authors. 
It is now admitted that a better expressiveness increases the probability to generate 
inconsistent documents. 

Hypermedia document presentations are real-time applications. Hypermedia 
presentations also depend on user interactions and are therefore dynamic. For 
instance, a media content may, depending on some user interaction, be presented 
either as a text or as an audio; presentation durations are accordingly different, and 
synchronization constraints are to be defined at presentation time. Consistency 
verification becomes much more difficult. 

Authoring systems usually postpone design validation to the run-time stage. This 
often happens too late, and the lack of well-established procedures makes the 
validation process uncertain. On the other hand, a complete formal approach is too 
complex for end-users, which prefer a high-level graphical language ranging from 
basic timelines to object-oriented models (Casanova, 1991) (Fraisse, 1996). The 
approach proposed in this paper is meant to allow the designer to use his or her 
favorite authoring tool. The latter's output is then automatically translated into a RT- 
LOTOS formal specification that is checked against design errors, using traditional 
verification techniques. 

2.2. Hypermedia authoring models 

Various informal and formal hypermedia modeling approaches have been proposed in 
order to describe the temporal structures of hypermedia documents. Main approaches 
have been classified into four categories (Blakowski, 1996): 

• Interval-based specifications offer several operators on temporal intervals that 
characterize elementary media with minimal synchronization constraints to be 
satisfied in a compound document (Wahl, 1994). 

• Axes-based specifications such as temporal lines are widely used in commercial 
tools but their lack of expressive power is notorious. 
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• Control Flow-based specifications include hierarchical trees, reference points as 
well as Petri net based models (Willrich, 1996). 

• Event-based specifications are the most expressive, but the price to pay is in the 
complexity of edition and update functions (Buchanan, 1993b) (Casanova, 1991) 
(Faisse, 1996). 

The hypermedia design approach presented in this paper is currently being 
implemented for hypermedia documents expressed in the Nested Context Model 
(NCM) the conceptual model of the HyperProp authoring system (Soares, 1995). 
NCM is a high-level authoring model based on the basic concepts of the 
hypermedia/hypertext community (such as nodes, anchors and links). It permits also 
to structure a complex hypermedia document by means of the composite node concept 
and belongs to the category of event-based specifications as far as the document 
temporal structure description is concerned. Basic features of the NCM authoring 
model will be introduced intuitively in the next paragraph. Details on NCM and the 
HyperProp system are available in (Casanova, 1991) (Rodrigues, 1997). A detailed 
comparison between NCM and hypermedia models used in Firefly (Buchanan, 
1993b), CMIF (van Rossun, 1993), I-HTSPN (Willrich, 1996) and others, with 
respect to temporal and spatial synchronization aspects as well as to the semantic 
power of their compositions, can be found in (Rodrigues, 1997). 

It is important to stress that the scope of the proposed design approach goes far 
beyond a particular authoring model or system, and could therefore be adapted to 
another one. 

2.3. Hypermedia documents based on compositions 

Hypermedia systems are characterized by the existence of complex relationships 
among the document components. Such systems also include mechanisms intended to 
structure the document in order to reduce the so-called lost in the hyperspace 
problem. Such a structured definition is desirable as it carries built-in concepts of 
modularity, encapsulation and abstraction. Conceptual models with composite nodes, 
like models that allow nested compositions, support such mechanisms. 

Nodes are fi-agments of information and links interconnect them into networks of 
related nodes. Anchors represent an area within the content of a node that may be 
associated either to the source or destination of a link. The NCM model goes one step 
further by distinguishing two basic classes of nodes, called content and composite 
nodes, the latter being the central concept of the model (Soares, 1995). 

Intuitively, the content node contains data whose internal structure, if any, is 
application dependent (they are the usual hypermedia nodes). The class of content 
nodes can be specialized into other classes {text, video, audio, image, etc.), as required 
by the applications. 

A composite node C is a node whose content is a collection S of nodes and links. 
Note that a component may be included more than once in 5. However, in this paper, 
we will assume links and nodes collection as a set, without loss of generality. An 
important restriction however must be done: a node cannot be recursively contained in 
itself. It is worth to note that composite node contains nodes and links, generalizing 
some models that group only nodes in compositions. 
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Composite nodes have several desired properties, such as: 

• Compositions nesting, that is, compositions that contain other compositions. 

• Grouping of the components of a document and the relationships among them 
independently of their types (synchronization relationships for presentation, 
selection relationships for usual hyperlink navigation, etc.). 

• Use of the composite nodes as a new type of node, in all senses, that is: 

- They can be presented - since in a presentation, it is important to exhibit 
not only the data content of a document, but also its structure as it is 
specified in the composite node (for example, when one accesses a book 
chapter modeled as a composite node, besides seeing its content, one may 
want to visualize its section structuring). 

- Different entry points in a composition can be defined, i.e., in a 
composition, components may have different presentations, depending on 
the entry point. For instance, the duration of a composition (duration of 
its component exhibition) will depend not only on the duration of its 
components, but also on the associated entry point. In HyperProp system, 
descriptor objects are used to specify how and with which tool the 
associated node will be presented. Using distinct descriptors, one can 
define different presentations for the same data object. For example, a 
media segment can be synthesized as an audio, using descriptor Di, or 
presented as a text using descriptor D 2 . 

- Relations among compositions can be defined. 

• Inheritance in the composition nesting, in the sense that relations can be 
defined in a composition C, referencing components recursively contained in 
C. This mechanism is extremely important in object reuse. 

• Composite node presentation to help user navigation through a document - 
what can require the use of some filtering mechanism to present the document 
structure in order to lessen the user disorientation. 

2.4. Example 

Figure 1 depicts the composite nodel that includes 4 content nodes (node2, node3, 
node4 and nodeS), and another composite node (composite node5), which includes 
two content nodes (node6 and node?). The name of each node is followed by a time 
interval, which represents respectively the minimal and the maximal duration defined 
for that node. The duration of the content node may be estimated by the document 
author depending on the quantity of information to be presented. For a composite 
node, the situation is a little bit more complex since the termination of the node 
presentation depends on the internal logic of the node. If one does not want to put any 
duration constraint on the node, one specifies only [0,oo] avoiding consequently the 
risk to induce undesirable temporal consistencies in the node specification. The global 
behavior of the document is characterized by composite nodel, which may informally 
be described as follows: 
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• The start of nodel leads to the immediate and concurrent start of node2 and 
node3 (see the link /;). 



• Within node2, two anchors have been defined. Node2 should terminate as soon as 
one of the anchors has been triggered. The selection of anchorl yields to start of 
node 4 starts 2s after the end of node2 (link U with delay 2s noted A^). The 
selection of anchor2 yields to the immediate start of nodeS, as soon as node 3 
terminated (link Is with a waitLatest logic). It is ftirther assumed that both 
anchors are timed, i.e. that their activation depend on additional time constraints: 
they can only be triggered after dmin (set here to 5s) and until dmax (set here to 
25s). Furthermore, one considers that anchorl is the default anchor, i.e. it triggers 
automatically when there is no user interaction during the time interval where 
both anchors are offered. 

• Node3 is a content node representing an audio; its duration is initially set to 52s. 
The end of this node triggers the start of nodeS (link fe). 

• Node4 is a content node representing a video; its duration is set to 20s. 

• Nodes is a content node representing an image; its minimal duration is set to 5s, 
and its maximal duration is undetermined (set to infinity). In fact, the presentation 
of nodes will end as soon as composite node5 ends (link hi); finally, the end of 
nodes, causes the end of nodel presentation (link I 12 ). 

• Composite node5 may be started 3s after the end of node4 or as soon as the link 
Is is triggered. As a consequence, node5 may be started with two different 
descriptors depending on the event which triggered its start; these descriptors 
have an impact on the internal structure of composite node5, i.e. the type of 
presentation for content node6 (either an audio or a text) and their associated 
duration. Node 7 contains a video, with a minimal duration of 10s. 
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• The end of node6 leads to the end of nodeV, which itself leads to the end of 
composite nodeS, which causes the end of nodeS. 



3. Translation from the high-level model into a RT-LOTOS 
specification 

The purpose is not to define a new formalism for the description of temporal 
structures in hypermedia documents. Instead, our goal is to formalize hypermedia 
objects defined in some high-level authoring model like NCM via a mapping of these 
objects onto a general-purpose formal description technique (FDT in short). The FDT 
is therefore completely hidden to the document authors. Having an FDT document 
specification, verification techniques, such as reachability analysis and model- 
checking, can be applied for analyzing application oriented properties of the design 
and consistency properties in particular. 

How to perform such mapping is the prime question. The selected FDT should 
have the following features in order to be useful as well as efficient: 

• It must have a formal semantics, and not only an intuitive one. 

• It should be based on compositions, in the sense that complex document 
structures should be expressed by general constructs. 

• It should be able to express non-deterministic behaviors, particularly interactions 
with the external environment (i.e., the users). 

• It should have the ability to express complex time-constrained behaviors. 

• It should be mature enough, and supported by software tools for automating the 
verification procedure. 

Process algebra meet the first three requirements and LOTOS becomes a strong 
candidate because it is an international standard. Since standard LOTOS is not able to 
express time-constrained behaviors, different extension proposals have been made 
within the international LOTOS community, and are currently being standardized. 
Among these proposals, we selected RT-LOTOS (Real-Time LOTOS) proposed at 
LAAS-CNRS, in particular because the RTL software tool is available and 
operational (Courtiat, 1995). The same approach may easily be adapted to the new 
emerging E-LOTOS standard once stabilized with an adequate tool support. 

3 . 1. The specification methodoiogy 

The approach developed in the paper addresses the formal semantics of the basic 
objects of a hypermedia document by providing a mapping between these objects and 
RT-LOTOS processes, and another mapping between object composition rules and 
RT-LOTOS process parallel compositions. The approach relies on general mapping 
rules, as well as on the definition of RT-LOTOS process libraries specifying the 
behavior of reusable basic hypermedia objects, like content nodes, links and anchors. 
The approach is therefore general and may possibly be fully automated within an 
authoring system. As previously mentioned, an experimental implementation is 
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currently being developed for the HyperProp autho-ing system. Even without any full 
automated translation procedure currently available, various RT-LOTOS 
specifications of documents authored in NCM have been produced using this general 
translation procedure which is currently being put in practice by means of templates. 

3.2. Hypermedia objects specification 

The overall architecture of the specification is presented in Figure 2, where the 
specification of a hypermedia document (process Hypermedia) is composed in 
parallel with a process representing the environment (process Users). 

Process Hypermedia is itself specified as the instantiation of a process specifying 
the document top level (composite) node, synchronized with a parallel composition of 
the processes describing the links defined for the nodes. These process models timed 
synchronization relationships among all components. 



hide user, start, end. trigger* endRequest in 

Hy penned ia[user, stan, end* trigger, endRequest] t[user]l Users[user] 
where 

process Hypennedia[user. start* end* trigger* end Request] : exit :- 
compositeNode(us^* stan, end, trigger, endRequest] (...) 

I[ start, end, trigger, endRequest] I 

{ ... paraliei composiuon of she differeni xynchranhat'wn Vmks ...) 

endproc 

process Users[user] : exit I- 

( ... specification of the user imeructions . .. ) 

endproc 



Figure 2 - Specification overall architecture. 

The basic structure in a hierarchical composition model of documents is the 
Composite Node. This general structure is described by the compositeNode RT- 
LOTOS process definition as presented in Figure 3. 

Process compositeNode has three formal parameters characterizing respectively the 
node ID, and its minimal and maximal presentation duration. It features five external 
gates: gates start and end associated with the start and end of the node presentation; 
gates user and trigger related to the capture of user interactions and to the trigger of 
an anchor, respectively; gate endRequest related to the termination of the node. All 
these gates are parameterized in order to identify the node ID and the media type (for 
gates start, end and endRequest), the anchor ID (for gates user and trigger). 

When process compositeNode is instantiated with some ID value and other 
parameters, the process first synchronizes on gate start. Using the recursive definition 
of compositeNode, one may note that the composite node may be re-instantiated 
again. Once the synchronization on start is performed, the behavior of the process is 
essentially described by process bodyNode together with the specification of the 
termination conditions of the composite node (see process endNode in Figure 3). 

Process bodyNode permits to select the body of the current composite node with 
respect to the node ID; assuming some generic node identifier i, the associated 
bodyNode process is bodyNodei; it describes the internal logical structure of 
composite node v, it is made up by the parallel composition of the RT-LOTOS 
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processes characterizing content nodes and/or other composite nodes nested within 
composite node i. 



process compositeNode[ start, end, user, trigger, end Requests grant} (ID, dmin, dmax : oat) : eidt 
let composite : nat = 0 in 
start !ID!cOTHposite; 

( ( body Node[ Stan, end, user, trigger, endRequest, grantJ(ID) 

1> endNode[endRequest,end] (ID4tnin.dmax) > 

III composjteNodel start, end, user, trigger. endRequest, gram] (ID, dmin, dmax) ) 

’H'here 

process bodyN ode [start, end, user, trigger, endRequest, gram] (ID;nat) ; exit ;= 

[ID == i] -> bodyNodei[stan, end, user, trigger, endRequest, grant] 

endproc 

process endNode[end Request, end] (ID,dm]n,dmax : nai) ; exit 
let composite : nat = 0 in 

delay{dmin) (endRequest nDlcomposite; endMDIcomposite; exit) 
l[end]l endf dmax-dnun) nDIcomposite; exit) 

endproc 

process bodyNodei] start, end, user, trigger. endRequest. grant] z exit := 

... Ill contentNode[start, end, user, trigger. endRequest, grant] (...) 

Ill ... Ill compositeNodefstait, end, user, trigger, endRequest, grant] (.. .) Ill ... 

I endproc 

! process contentNodef start, end, user, trigger, grant) (ID. dmin, dmax, media : nat) : exit := 
stanllD! media; 

grant lmedia?dstan:nai!mie; delay(dstart) (( delay(dmin) end] dmax -dmin }!iD!media; exit ) 

III contentNode[stan, end, user, trigger, grant] (ID, dmin, dmax, media) ) 
endproc 



Figure 3 - compositeNode and contentNode generic process definitions. 

The general structure of a content node is described by the contentNode RT- 
LOTOS process presented in the bottom of Figure 3. This process is much simpler 
than the previous composite node specification, since there are no more nodes nested 
within a content node. The content node specification forces the termination of the 
node according to the minimal and maximal duration defined for this node. As 
previously for the composite node, one can note that process contentNode may be 
defined recursively. 

As suggested by the excerpts of the formal specification described in, the approach 
did not try to get the most readable formal RT-LOTOS specification, but instead the 
most general (with respect to the expressive power of the NCM model) and generic, 
based on reusable components. The goal has been to completely automate the 
derivation of the formal specification from an NCM authoring. As a consequence, our 
specification methodology is based on the identification and formalization of several 
process libraries characterizing, basic content nodes, basic links, basic composition of 
nodes and links and basic termination conditions respectively. Some components of 
these libraries have been inherited from previous work on a simpler hypermedia 
synchronization model (Courtiat, 1996). 
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4. Consistency verification 

Using formal methods within the context of a high-level authoring tool brings two 
main advantages. First, it provides a formal semantics to the high-level authoring 
model, describing without any ambiguity the behavior of a document presentation. 
Second, it permits to check consistency properties on the formal specification derived 
from the authoring model, using standard verification techniques. 

4. 1 Reachability analysis of RT-LOTOS specifications 

The verification techniques developed and implemented for RT-LOTOS within the 
RTL software tool (Courtiat, 1995) consist in applying reachability analysis to the 
timed automaton model into which the RT-LOTOS specification is compiled. The 
method implemented in RTL is characterized by two important features: 

• It permits to minimize the number of clocks in each control state of the timed 
automaton, thanks to the definition of the DTA (Dynamic Timed Automaton) 
model. 

• Reachability analysis may be performed on the fly during the DTA generation. 

The resulting graph is a minimal reachability graph. Each node of the graph 
represents a reachable class which may include an infinite number of elements 
depending on the value of the current time. Each arc of the graph corresponds either 
to an action occurrence {i.e. an event) or to a global time progression (in this case, the 
arc is labeled by action time). 

RTL tool has further been interfaced with other tools: BCG for labeled transition 
systems display, and ALDEBARAN (Fernandez, 1996) for deriving a minimal 
automaton from a labeled reachability graph with respect to an equivalence relation 
(for instance, the observational equivalence). 

4.2 Consistency properties 

Hypermedia documents are expected to satisfy temporal consistency properties stating 
that temporal synchronization constraints to be met during the document presentation 
are not in conflict with one another. Depending on how these synchronization 
constraints are defined, there exists indeed a risk to create inconsistent situations, i.e. 
situations where different contradictory synchronization requirements cannot be 
satisfied together, leading to undesirable deadlocks (global or partial) during the 
document presentation. 

By definition (Courtiat, 1996), we consider that a document presentation is 
consistent^ if the action characterizing the start of the document presentation is 
necessary followed, some (finite) time later, by an action characterizing the end of the 
document presentation (Property PI). As a consequence, action end should be always 
reachable from the initial state of the RT-LOTOS minimal reachability graph, 
assuming that, by construction of the RT-LOTOS specification, action start is the 
unique action to be enabled in the initial state. The definition also implies that there is 
no divergence (i.e. no undesirable loop) within the reachability graph. 
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The above definition is related to a document presentation. Within the framework 
of our authoring model, the definition may also be applied to a composite node 
presentation. 

In order to distinguish different consistency properties, let us call PI an intrinsic 
consistency property (Santos, 1998). It is said to be intrinsic because it is independent 
of any particular multimedia resource used for the document presentation. Many 
reasons may lead to temporal intrinsic inconsistencies, when one uses a high-level and 
powerful authoring model like NCM. For examples which seemed a priori not too 
complex, the following situations were encountered: inconsistencies between the 
expected duration of the nodes and the logic of the synchronization links enforcing 
their termination, conflicting synchronization links, bad timing of the synchronization 
links, omission of some default cases (for instance, what happens for a node featuring 
several anchors, when none of them is triggered by the user: should the node 
terminate or not? What the impact on other nodes?) 

Another interesting consistency property (called extrinsic consistency property, or 
consistency property P2) to be proved when a document presentation is related to 
potential undesirable concurrent accesses to some multimedia presentation resources 
(Santos, 1998). A simple example includes an erroneous attempt to mix different 
audio signals on the same audio channel (sound card + loudspeakers). A complete 
specification of these consistency properties would probably require to define a high- 
level RT-LOTOS specification of the multimedia platform on which the document is 
supposed to be presented and to compose this specification with the RT-LOTOS 
specification of the document. Such a study is being carried out at LAAS-CNRS, but 
it is not reported in this paper. We will see however how some extrinsic consistency 
properties may be proven without developing any formal model of the underlying 
multimedia platform. 

4.3 Verification approaches 

Two complementary approaches have been investigated in order to prove consistency 
properties: global reachability analysis and node aggregation. 

4.3.1. Global reachability analysis. This classical approach consists in performing 
the reachability analysis on the RT-LOTOS specification derived from the entire 
document. Its main limitation is related to the state space explosion problem. If one 
nevertheless succeeds in building the reachability graph, the latter can be transformed 
into a labeled transition system (LTS) whose observable events are appropriately 
selected with consistency properties verification in mind (typically, the start and end 
of the document or node, the time progression action, the user interactions). Other 
events may de facto be hidden. The LTS can be minimized using, e.g., observational 
or safety equivalence relations, which are both supported by the ALDEBARAN tool. 

4.3.2. Node aggregation. Validation by node aggregation is bottom up. We first 
select a composite node and perform reachability analysis on it. The resulting graph 
together with the minimized automaton output by ALDEBARAN may be used to 
prove, on this composite node, the required consistency property. Once the 
consistency of the composite node has been established, one knows, according to the 
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consistency definition, that the occurrence of the start action of the composite node is 
followed some (finite) time later by the occurrence of the composite node end action. 
The idea is then to replace the composite node specification by a content node 
specification whose minimal (dmin) and maximal (dmax) duration are directly derived 
from the internal timing logic of the composite node. We sketched an algorithm which 
derives dmin and dmax information from the composite node global reachability 
graph. This algorithm relies on the reachability graph clock regions and the analysis 
of the enabled transitions, taking into account the general structure of the composite 
node specification. However, we did not get any proof of the algorithm correctness, 
but experimented successfully its .“supposed” validity on different examples. Once we 
get this timing information, we come up with the following conjecture: any composite 
node may be replaced by an “abstract” content node whose start and end actions are 
similar to the composite node’s start mi end actions, and whose (possibly non 
deterministic) global delay is computed from the composite node’s internal timing 
logic. The required congruency has not been formally proved, but seems to be a direct 
consequence of the rather particular structure of a consistent composite node (one 
start action, followed by several branching actions which are hidden within the 
composite node and without any divergence, leading finally to the unique end action). 
Further work is required in this respect, but the aggregation method appears to work 
well in practice, since it permits to analyze complex structured hypermedia documents 
composite note by composite node instead of globally. 

4.4 Illustrations 

In this section we survey some verification results achieved for the hypermedia 
document presented in the section 2.4. 




Figure 4 - Document minimal automaton. 

Figure 4 presents the minimal automaton^ of the whole document reachability 
graph, where only actions start and end of all nodes (composite or not), user (for 
anchors selection), timeout (for the automatic trigger of anchorl), time (for time 
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progression) have been selected as visible actions. The graph shows that there is no 
visible loop, and that action stand (i.e. the start of compositeNodel) leads 
eventually to endCl. As a consequence, the document is intrinsically consistent. The 
fact that there is no hidden internal loop is a direct consequence of the RT-LOTOS 
semantics. The invisible internal actions are indeed urgent actions, and a loop among 
these actions will stop the time progression; now, one can note that any stan action is 
always followed by a time progression action before achieving the corresponding end 
action. 




Figure 5 - Document minimal automaton (with node aggregation). 

Figure 5 presents the minimal automaton of the global reachability graph which 
has been derived from the document RT-LOTOS specification, where composite 
nodes has been replaced by an abstract content node (following the aggregation 
method discussed previously). This graph is observationally equivalent to the minimal 
automaton derived from the graph of Figure 4, with actions stanN6(A), stanN6(T), 
stanNJ, endA6(A), endN6(T), and endN7 htmg invisible. 




Figure 6 - Inconsistency situation (intrinsic). 

Figure 6 presents the same graph as Figure 4 with the difference now that the 
duration of node3 has been set to 100s instead of 52s. One can see that such a 
specification leads to an intrinsic inconsistency since the stan of nodeS (action 
stanNS) may occur after the end of nodeS (action endC5)\ and yet, we specified that 
the end of nodeS should lead immediately to the end of nodeS, hence the 
inconsistency since action endCl may be not reachable from the initial state. 
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Figure 7 - Inconsistency situation (extrinsic). 

Figure 7 considers the same initial case previously analyzed in Figures 4 and 5. 
The minimal automaton is constructed considering as visible only the actions starting 
and ending presentations of audio nodes (either audio content nodes or composite 
nodes including an audio node), plus the user, timeout and time actions. Analyzing 
this automaton, one can see that the document specification does not satisfy 
consistency property P2 (see the concurrent access to an audio channel), since for 
some behaviors depending on the time at which the user has selected an anchor, the 
start of an audio presentation is followed by the start of another audio presentation, 
without the end of the previous presentation; hence an inconsistency, leading to an 
undesirable mix on the same audio channel of two audio presentations. For the 
construction of this automaton and for clarity purpose, startNS (respectively endN3) 
has been relabeled startAudio3 (respectively endAudio3), and startN6(A) (respectively 
endN6(A)) has been relabeled startAudio6 (respectively endAudio6). 

This extrinsic inconsistency may be corrected by different ways: either by 
decreasing nodeS duration, by modifying the version of node6 considering a textusJ 
presentation instead of an audio, or more probably by adding a new link in the 
document specification. Thus one can see that error corrections are made at the level 
of the authoring model, which are then translated into the RT-LOTOS formal 
specification, following the translation procedure of section 3. 



5. Conclusions 

As a conclusion, one can stress the following points. First, it is extremely easy and 
flexible to work with high-level models at the authoring stage. Second, it is easier for 
the author to handle document logical structuring than only document presentation 
structuring. Hence, models based on compositions allowing every type of 
relationships among their components become very important. Third, the use of a 
hidden formal description technique, like RT-LOTOS, brings two important 
advantages: (i) it provides a formal semantics for high level hypermedia models, 
permitting a better understanding of some critical behaviors that may be expressed by 
the model (ii) it allows applying, when possible, exhaustive verification techniques to 
check a document against design errors. More work is currently devoted to the study 
of the extrinsic properties, taking into account additional delays that may be forced by 
an underlying multimedia platform. The limitation of the proposed method is related 
to the state space explosion of the reachability graph. The definition of the 
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aggregation method, which remains to be formalized and proved, appears to be an 
important step towards the verification of complex structured documents. 



Endnotes 

1 . Only temporal constraints are considered in this paper; note however that some ideas may probably be 
generalized to spatial synchronization. 

2. For simplification purpose, we do not consider in this definition the case where one wants, in the 
middle of a document presentation, restart the whole presentation; in that case, a start of a document 
could be followed by another start, and so on. 

3. All the minimal automata referred to in this paragraph are related to the observational equivalence. 
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Abstract: Frameworks have emerged as a very effective way to achieve reuse. A frame- 

work provides the basic structure and behaviour of a family of applications, 
and they simplify the task of application development. Traditionally the 
framework idea has not been applied to FDTs. This paper contributes to the 
use of SDL for building frameworks. SDL offers the opportunity to encapsu- 
late object structures and default behaviour in frameworks defined by SDL 
system types. Specific types of applications are obtained by defining sub- 
types of framework system types and redefining virtual types. The mecha- 
nism is not specific to SDL, but can be applied to any language that supports 
virtual types. 
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1 WHAT IS A FRAMEWORK? 

A framework is a reusable, “semi-complete ” application type that can 
be specialized to produce custom applications. The main property that dis- 
tinguishes a library from a framework is that a framework embodies a 
design of a type of systems, while a library just is a collection of related 
classes. An elaboration of this distinction is given in Table 1. 



Table 1: Library and Framework 



Library 


Framework 


The application uses library 
classes, but the library knows noth- 
ing about the application 


The framework knows about the 
application and uses application 
classes 


No predefined system structure. The 
system is entirely defined in the 
application 


Provides structure. The system is 
(partially) defined in the framework 


No predefined interaction 


Defines object interaction 


No default behaviour 


Provides default behaviour 



Classical frameworks like window systems are defined as a set of related 
classes. The structure of these frameworks results from dynamically created 
objects that are kept together by object references. The event loop that dis- 
patches mouse and keyboard events to window objects will use a list of cur- 
rently active window objects. This list will typically contain different 
window objects, with the common property that they react on these events. 
The default behaviour of the framework is to call virtual procedures or call- 
back procedures. The user of the framework redefines these procedures to 
what is special for the application. 

The paper does not address the definition of frameworks by means of 
composition of components with so-called “hot-spots” where components 
may be exchanged dynamically. Component-based frameworks rely on a 
black-box approach: the user of a component only knows its interface and 
cannot apply specialisation in order to cover specific needs. 




183 



2 WHY MAKE FRAMEWORKS USING SDL? 

Experience from SDL based development has shown that SDL systems 
often contains an application specific part and an infrastructure specific part 
(implementation specific) which are not clearly separated. The reason is that 
an abstract (application specific) system has to be supplemented by a large 
infrastructure part in order to be executable on a given platform. These two 
parts need to be combined for the purposes of complete system simulation 
and automatic code generation, but they serve different purposes and follow 
separate evolution patterns. Therefore an approach is needed that will allow 
these parts to be efficiently combined into complete systems, while keeping 
the parts identifiable for evolution and maintenance purposes. A solution to 
this divide and combine problem is to make a framework in SDL. Instead of 
making the infrastructure part again and again for each new system with the 
same infrastructure on the same platform, a framework that embodies both 
the application part and the infrastructure part is useful. The idea is that if a 
specific system can be made as an instance of a framework, with much of 
the general properties of the framework isolated in the infrastructure, then 
the framework will have a potential for being reused as a design. Further- 
more application development may concentrate on the central application 
issues and disregard the infrastructure, while infrastructure development 
may concentrate on the central infrastructure issues and disregard the appli- 
cation. 

In an initial development, the infrastructure aspect may not be obvious. 
Frameworks will often come as a result of a (successful) initial develop- 
ment, which is to be used as a basis for a new system. If e.g. distribution has 
been considered and isolated in an infrastructure part, the next system with 
the same infrastructure, but with a different application part can reuse this 
framework. The basic idea is that the infrastructure shall provide some gen- 
eral support to the application, and that application development may con- 
centrate on the application parts. 



3 HOW TO MAKE FRAMEWORKS IN SDL 

The distinction between a library and a framework is in SDL directly 
reflected by the language concepts Package and System Type. An SDL spec- 
ification can be either a package specification or a system specification. A 
Package in SDL defines a set of types, while a System (Type) defines both 
local types and a set of related instances. The interpretation of a system 
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specification yields a system instance that is the outmost container of all 
instances in a system. 

3.1 System types 

An SDL system consist of blocks. A block contains processes that are 
extended finite state machines communicating by means of asynchronous 
signal exchange and remote procedure calls. Blocks are connected by chan- 
nels, while processes are connected by signal routes. The connection points 
are called gates, and they are defined as part of the block- and process types. 
In object oriented terms, process types correspond to classes of “active” 
objects, while block types correspond to classes of “container” objects. 
Gates define simple interfaces in terms of which signals and remote proce- 
dures that are allowed. SDL have more entity kinds than system, blocks and 
processes, but for the purpose of this presentation only these are used. The 
notion of specialisation by means subtyping applies to most of the entity 
kinds of SDL, and also to system. A framework can therefore be defined by 
a system type in SDL, and a specific application of the framework by a sub- 
type of the system type. 

The framework system type will have a structure where some compo- 
nents may be classified as infrastructure- and some as application compo- 
nents, see Figure 1. The framework will have virtual types for those 
components that should be adapted to specific applications of the system 
type. These virtual types will be redefined when the framework is used as a 
supertype when defining the system type for a given application. In Figure 1 
the system type is defined to consist of a number of blocks. The types of two 
of these are defined as virtual block types, and can as such be redefined in a 
subtype of the system type. The redefinitions imply that the instances (A1 
and II) specified as part of the framework system (superjtype will have 
redefined properties. The structure specified in the supertype is inherited, 
while the “contents” of the instances are redefined. 

The dashed boxes in Figure 1 are not part of the SDL specification, but 
indicates the distinction between application- and infrastructure compo- 
nents. The actual borderline between these may not be as sharp as indicated. 

Virtual types do not distinguish between being infrastructure or applica- 
tion component types, so infrastructure component types can also be defined 
as virtual type in order to allow the infrastructure to be adapted to the spe- 
cific application. 
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Figure 1: A framework as a System Type 



3.2 Applications 

In many cases the application components are blocks with some infra- 
structure specific parts. The block type ATI, see Figure 1, may consist of an 
infrastructure and an application specific part, each represented by a virtual 
process type. This is illustrated in Figure 2. This also illustrates that the bor- 
derline between application and infrastructure parts is not so sharp as indi- 
cated in Figure 1 . 
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ATl_p and m_p are 
two virtual process types, 
and Appl and Infra are 
processes of these types. 

When redefining the vir- 
tual block type ATI, the 
virtual process types in 
this may also be rede- 
fined. If the application 
specific part is to be 
adapted, then the virtual 
process type ATl_p is 
redefined. If the infra- 
structure part shall be adapted, then ITl_p is redefined. 

3.3 Instances as part of frameworks 

As described above, the way a framework is adapted to specific needs is 
by redefining virtual types. Redefining virtual types will, however, have no 
effect if the virtual types are not used to specify instances. These instances 
may either be specified as part of the framework or be specified as part of 
the specific use of the framework. 

3.3.1 Application specific instances specified as part of the frame- 
work 

In this case the framework defines the structure of instances with their 
connections in terms of channels and signal routes. This is the approach 
used in Figure 1 and Figure 2. SDL is special in the sense that a static struc- 
ture of instances and instance sets can be specified - instances are not just 
created dynamically. In a specific application, the properties of the instances 
are provided by redefining the virtual types, while the structure and connec- 
tion of instances are inherited from the framework. 

The structure of instances and their connections in the framework are 
obtained by connecting gates of the instances with channels and signal 
routes. The properties of the instances may be redefined when a specific 
application is made, but the interconnections between gates cannot be rede- 
fined. Gates are defined as part of the virtual types, and as gates are used for 
connecting instances, the redefinition of these must be constrained. It is 
important that the framework specification can be analyzed (e.g. that the 




Figure 2: A virtual block type as part of 
framework, with appUcation specific in- 
stances and infrastructure instances 
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connections are valid), and that this analysis is valid for any application of 
the framework. 

This requirement is fulfilled by the notion of virtual type constraint. A 
virtual type in SDL has a constraint (in terms of a type of the same kind), 
and a redefinition of the virtual type must be a subtype of the constraint. The 
default is that the constraint of the virtual type is the type definition itself. 
The gates necessary for the connections - specified as part of the framework 
- are properties of the virtual type constraints, and are as such guaranteed to 
be properties of any redefinitions. 

If the structure is so that 
the same virtual process 
type is used to make 
process sets in many 
parts of the system 
structure, then the vir- 
tual process type should 
be moved to the system 
type, see Figure 3. In 
this way it can be rede- 
fined at one place as 
part of the system sub- 
type and have implica- 
tion on many parts of 

the system. 

Application specific instances may be added either statically as part of 
the subtype system definition, as illustrated in Figure 1 (block A2), or they 
may be created dynamically. Dynamic creation of application instances are 
anticipated in Figure 2: the Appl specifies a set of maximum 5 processes of 
type ATl_p. The dashed arrow specifies that the Infra process creates pro- 
cesses in the Appl process set. If new process sets are added in redefinitions 
of the enclosing virtual type (here ATI), then the infrastructure process must 
be redefined accordingly to take care of their creation. 

3.3.2 Application specific instances not specified as part of the 
framework 

In this case the framework only consists of general types that may be 
used for the construction of the application part. The infrastructure parts 
may either contain instances or just be represented by types. 



system type FrameWork2 



virtual ATI 



virtual ITl 



virtual ATl_p 



Figure 3: A framework where an applica- 
tion process type is common to many parts 
of the framework 
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In this situation the creation must be anticipated by the infrastructure. 
SDL is special in the sense that processes are part of process sets and that 
creation of processes is done by referring to the name of the set and not to 
the name of the process type. It is therefore not enough that the infrastruc- 
ture specific process types are defined in the same scope (e.g. a package or a 
system) as the application specific types and thereby know these types - 
they must have means for referring to the process sets that will be part of the 
specific system. 

SDL provides two means for this: context parameters and virtual proce- 
dures. 

Context parameters 

The general types of the framework that have to create process instances 
according to application specific types do this through process context 
parameters. The actual process context parameter is the process set being 
part of the specific application. 



system type FrameWork3 




virtual AT3 




virtual IT3 








1 



system type Application2 
inherits FrameWork3 



redefined AT 3 



A3: AT3 



system SpecAppl : Application2 



Figure 4: A framework with no instances 

The scheme is illustrated in Figure 4, Figure 5, Figure 6 and Figure 7. 
Within the block types, there will be general process types (infPT and appli- 
cationPT) that are used as supertypes in specific systems inheriting from 
Frame Works. 

The infPT process type shall create instances of type applicationPT, and 
to this purpose it will have a process context parameter that is constrained 
by applicationPT, see Figure 7. The idea is that a particular system will pro- 
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virtual block type AT3 



virtual 

applicationPT . 

N ^ 








infPT 


1 







Figure 5: A virtual Application 
block type without instances. 

vide its redefinition of applicationPT and its process set. By means of the 
context parameter, the infPT processes will be able to create instances of the 
redefined applicationPT without knowing the final process set. 

The final system type will introduce the redefined block types with 
appropriate process sets, see Figure 6, and provide these as the actual con- 
text parameters. 



redefined block type ATS 




process type specialapplicationPT 
inherits applicationPT 








process type specialinfPT 
inherits inf PT<actualPT> 




"^ 0 tualPT ( 0 , ) : ^^ctualinf : 

specialapplica- ^ specialinfPT 

«„^tionPT ^ L y 


: 1 



Figure 6: Redefined block type with process set 
and actual context parameter 

The difference from the case with application specific instances as part 
of the framework is not so big: the process set must be foreseen (the context 
parameter must be defined - and correspond to a process set), but the name 
of it and its position in the application part is not determined. Its position 
will, however, be constrained by the fact that it shall be visible from the 
place where the actual context parameter is provided, and that it shall be cre- 
ated by a process in the same block. 
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process type infPT 

<process cp atleast applicationPT> 



. . . . create cp ( . . . ) 



Figure 7: Creation of application specific processes 

Another constraint with this approach is that it is not possible to specify 
instance sets of the infPT in the framework itself. The reason is that this pro- 
cess type has context parameters and therefore cannot be used for instance 
specification. 

This approach should only be used in cases where it is important that the 
framework specific and application specific process types can be defined 
within the same enclosing block type and where the framework specific 
types must specify the creation of application specific processes. 

Virtual creation procedures 

This approach is more general in the sense that it does not have to be 
decided if there is one or several process sets in the final system type. In the 
general types where there is a need to create application specific processes, 
this is represented by corresponding virtual procedures. In the final system 
type these are redefined to create processes in the actual process sets. 

This approach also has the property that instance sets of the application 
specific types are first introduced in the final system subtype. 

In order to provide an example on this way of making frameworks, we 
use Figure 8. Suppose that it is a requirement that the system shall start by 
creating processes for each of the actual applications and that changes to the 
number of application processes shall be reflected while the system is run- 
ning. Still we would like to define the system as a framework in the sense 
that it will consist of a common infrastructure and some dynamically cre- 
ated application instances. We assume that the division of responsibility 
between the two are determined, the communication is fixed and that the 
functionality of the infrastructure is specified - the only thing that is not 
specified is the types and numbers of application processes. The configura- 
tion of the system is initiated by a new signal (setUp, with appropriate 
parameters) coming to the infrastructure part of the system. 




191 





Figure 8: Framework with virtual creation procedures 

The setUp signal is supposed to come to the inf process and imply the 
creation of application processes in the right process sets. Depending on the 
desired number and types of application processes, the signal will carry 
enough parameters for the infrastructure to create the right instances. 

The infrastructure types can now be defined as before, the only differ- 
ence being that they will have a virtual procedure setUp and will communi- 
cate with possible application processes via a gate that is constrained by 
Application - that is only process sets of Application or subtypes of Appli- 
cation can be connected to the gate, see Figure 9. 

In addition to the normal behaviour and the creation of application pro- 
cesses, the Infrastructure may have behaviour that contributes to the defini- 
tion of the framework. As an example there may be a limit on the total 
number of application processes, independent of type of application. The 
behaviour that ensures this will either be part of the infrastructure, e.g. some 
action executed each time setUp is executed, or it may be a constraint on 
setUp which all redefinitions will inherit. 

An actual system consisting of two types of application processes is 
specified as a subtype of the system type Framework4, redefining the setUp 
procedure to cater for this and introduce the two process sets, see Figure 10. 

The names of the process sets are used in the redefined setUp procedure 
for the specification of the creation of process instances. 




193 



4 RELATED WORK 

4.1 Virtual classes/design patterns 

The notion of virtual types with constraints where first introduced in 
BETA (Madsen, Mpller-Pedersen & Nygaard, 1993) in terms of virtual pat- 
terns. Patterns in BETA is a generalisation of language concepts like class, 
type, procedure, etc. Virtual procedure patterns provides what is common in 
most object oriented languages: virtual member functions or methods that 
can be redefined. The use of virtual patterns to obtain virtual classes is 
described in (Madsen & Mpller-Pedersen 1989). 

In (Agerbo, 1998) virtual classes are used to express some design pat- 
terns by means of language constructs. It is argued that a design pattern 
should not be covered by a language construct, in order to be a design pat- 
tern, and they show that the Factory Method design pattern can be expressed 
by a virtual class for the class that varies with the different applications of 
the design pattern. 

Virtual block types and virtual process types as described above for SDL 
corresponds to virtual classes. A requirement for using this approach to 
framework definition is therefore that the language has virtual classes. Most 
object oriented languages do not have classes within classes, with Java 
(Arnold &Gosling, 1996) and BETA as exceptions. 

Component based software development, with solutions based on e.g. 
CORBA, COM or Java Beans, represents another approach to the definition 
of frameworks. While the approach described above relies on access to the 
source so that specialisation can be used to express adaptation to specific 
needs, component based frameworks relies on applications with so-called 
“hot-spots”, that is components that can be exchanged with components 
with the same interface. 

4.2 Frameworks in The Integrated Method - TIMe 

TIMe is a comprehensive development methodology that uses UML , 
MSC and SDL as its primary languages for analysis and design. It empha- 
sises that SDL is used to make models that are both readable, formal and 
sufficiently complete for extensive simulation and automatic code genera- 
tion. TIME recommends that design is carried out in three main steps: appli- 
cation design, architecture design and framework design, where application 
design and framework design are abstract models expressed primarily in 
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SDL and MSC (possibly using UML for parts where SDL is not well 
suited). 



4.2.1 Application design: where the service functionality is designed 

The first purpose of an application design model is to describe the sys- 
tem behaviour at an abstraction level, where it can be understood and analy- 
sed independently of a particular implementation. 

The second purpose is to be a firm foundation for designing an optimum 
implementation satisfying both the functional and non-functional require- 
ments. 

4.2.2 Architecture Design: where the implementation architecture is 
decided 

The purpose of architecture design is to design an implementation archi- 
tecture that will behave as defined in the application design model and sat- 
isfy the non-functional properties. The purpose of architecture design is to 
answer how the system is going to be realised. This is expressed using 
Architecture descriptions that show: 

• the overall architecture of hardware and software; 

• how frameworks and applications are mapped to the architecture. 

While the application and the framework has focus on functional proper- 
ties and behaviour, the architecture has focus on non-functional properties 
and physical structures. The purpose is to give a unified overview over the 
implementation and to document the major implementation design deci- 
sions. 

Architecture design determines critical architectural issues such as phys- 
ical distribution, global addressing schemes and fault handling. Some of 
these may subsequently be reflected in the framework model in order to 
describe the complete system behaviour. 

During normal application evolution, the architecture will be stable, and 
system evolution can take place mainly at the Application level. 

In an initial development, architecture design will come before frame- 
work/infrastructure design. 
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4.2.3 Framework Design: from Infrastructure to Framework 

The purpose of framework design is to describe the complete system 
behaviour taking the underlying implementation as defined in the architec- 
ture design into account. In this step the implementation dependent infra- 
structure functionality is taken into account, e.g. distribution support, error 
handling and configuration. The infrastructure part of a system contains 
additional behaviour needed to fully understand what the system does (i.e. 
the complete system behaviour). Here we find objects and parts of objects 
that support distribution, system administration and other facilities not 
directly related to user services (applications). Whenever practical, the 
application and the infrastructure should be put together in a framework that 
serves to simplify the definition of new systems and separate the evolution 
of applications from the evolution of infrastructures. The framework model 
defines a system type or a block type, with predefined structure so that a 
specific application system only has to provide the specific “contents” of 
part of this structure using the approaches explained earlier. 

An application system designed before the infrastructure was known. 



application specific 










1 1 1 

infrastructure specific 
__ . _J 1 1 







Figure 11: A framework with application and infra- 
structure specific parts of systems 



may have to be redesigned somewhat in order to satisfy the infrastructure 
interfaces. Restructuring does not mean that everything has to be redefined, 
only those parts that depend on the infrastructure. When the infrastructure is 
known, new application types may be defined right away to comply with the 
infrastructure interfaces. 

In general it will be an advantage if the application design has been done 
by means of types that are as general as possible. 

When the framework has been defined, making a specific system 
instance is a matter of exchanging the application types of the framework 
with either improved versions or new application types with e.g. new func- 
tionality. 
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5 CONCLUSIONS 

The notion of a framework has a potential to be very useful when mak- 
ing abstract system models using FDTs, especially when the models are 
complete and used as basis for system evolution and code generation. This 
paper has only considered the possibility of making frameworks using SDL. 
However, the underlying needs that are addressed and the potential benefits 
of using frameworks are independent of the FDT actually used and by no 
means restricted to SDL. The important thing is that the language of the 
FDT is able to support frameworks in an efficient way. As has been demon- 
strated in this paper, SDL provide some basic features that make frame- 
works possible. Using these, a divide-and-combine approach to application 
and infrastructure development is possible that enable a high degree of 
reuse, and simplify system evolution. 
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Abstract 

SDL patterns are reusable software artifacts. They represent generic solutions for 
recurring design problems with SDL as applied design language. We have developed a 
construction set of protocol building blocks consisting of a pool of SDL patterns and 
an accompanying methodology for the incremental design of communication proto- 
cols. In this paper, we present a case study on the specification of communication pro- 
tocols based on SDL patterns. The case study is part of a more comprehensive project, 
where a real-time communication subsystem was developed on top of a Controller 
Area Network (CAN) installation. We demonstrate how the protocols supporting user 
communication and certain management tasks were configured. We also applied the 
SDT Cadvanced code generator to implement the resulting design specification on a 
PC cluster. Generally, it turned out that SDL-pattern based configuring of communica- 
tion protocols yields more systematic designs, i.e., readability and maintainability is 
improved and less design errors occur, since the design decisions are well founded and 
documented. 

1. Introduction 

The reuse of predesigned solutions for recurring design problems is of major concern 
in object-oriented software development. During the past few years, design patterns 
have emerged as an especially fruitful approach to software reuse [2] [5]. Contrary to 
the traditional paradigm of class and function libraries, which is solely concerned with 
code reuse, design patterns aim to focus on the invariant parts of a design solution and 
offer by far more flexibility for adaptation to the embedding context. That is, the 
potential of reuse is substantially increased. There are several advantages commonly 
attributed to design patterns: patterns capture solutions, which have evolved over time 
and serve as an elegant way to make designs more flexible, modular, reusable, and 
understandable. They reflect experiences gained in prior developments and therefore 
help designers to reuse successful designs and architectures. As a consequence, the 
design process becomes faster and the number of design errors decreases. 



* This work is supported by the German Science Foundation (DFG) as part of the Sonderforschungsbereich 
SFB 501 Development of Large Systems with Generic Methods. 
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In [6] [7] we present the SDL-pattern approach that integrates the design patterns 
concept with SDL [11], Generally speaking, SDL patterns describe generic solutions 
for recurring design problems, which can be customized for a particular context. While 
conventional design patterns are specified independently from a possible design lan- 
guage, it is assumed that the target language for SDL pattern instantiation is SDL. 
Thereby we benefit from the formal basis provided by SDL, so that SDL patterns actu- 
ally characterize as formalized design patterns. Instead of specifying and applying the 
patterns rather informally, a formal target language such as SDL offers the possibility 
to precisely specify how to apply a specific pattern, under which assumptions this will 
be allowed, and what properties result for the embedding context. This is a major 
improvement compared to conventional design patterns, which mainly rely on natural 
language based pattern description and still have to leave pattern application to a large 
degree to the personal skills of the system designer. However, we do not deal with for- 
malizing design patterns in general. Instead of formalizing reuse concepts we aim to 
support reusability within the formal methods area. 

In this paper, we present a case study on the specification of communication proto- 
cols based on SDL patterns. The case study is part of a more comprehensive project, 
where a real-time communication subsystem was developed on top of a Controller 
Area Network (CAN) [3] installation. We demonstrate how the protocols supporting 
user communication and certain management tasks were configured. We also applied 
the SDT Cadvanced code generator to implement the resulting design specification on 
a PC cluster running under the real-time operating system QNX. 

The remainder of the paper is organized as follows: Section 2 introduces the SDL- 
pattern approach. In Section 3 we demonstrate how a real working communication 
subsystem for CAN was configured using SDL patterns. The development steps for 
(semi-)automatic code generation of the resulting SDL design are outlined in 
Section 4. Finally, we summarize the results in Section 5. 

2. The construction set of protocol building blocks 

This section summarizes concepts for a construction set of protocol building blocks, 
from which a protocol designer can select SDL patterns and configure them to a cus- 
tomized, formal protocol specification. 

2.1. SDL patterns 

An SDL pattern describes a generic solution for a recurring, context-specific design 
problem. It is assumed that the target language for pattern instantiation is SDL. 
Though the concept is not restricted to a specific application domain, we are mainly 
concerned with communication protocols. 

For the specification of SDL patterns we have defined a standard description tem- 
plate with the main items sketched in the following. The mere syntactical part of the 
design solution is defined by a generic SDL fragment, which has to be instantiated and 
textually embedded into the context specification when applying the pattern. SDL 
fragments represent context invariant parts of the design solution. Instantiation and 




199 



embedding of SDL fragments is prescribed in terms of syntactical embedding rules, 
which, e.g., guide renaming of generic identifiers or specialization of embedding 
design elements. Usually pattern semantics is not completely captured by an SDL frag- 
ment. Due to language constraints this would otherwise result in an overspecification 
of the design solution and reduce potential of reuse. Thus additional semantic proper- 
ties are included specifying preconditions for pattern application as well as behavioral 
changes of the embedding context. Though semantic properties are currently stated in 
natural language, it is possible to express them precisely in a temporal logic. Also, 
restrictions on the refinement of pattern instances are specified in order to prevent a 
pattern’s intent from being destroyed by subsequent development steps. A more 
detailed discussion of the SDL-pattern description template and a comparison to exist- 
ing description templates of conventional design patterns is given in [6]. 

The current pool of protocol building blocks contains SDL patterns that deal with 
interaction behavior of distributed objects, error control (lost or duplicated messages), 
lower layer interfacing, or dynamic creation of protocol entities. To further illustrate 
the functional scope of SDL patterns we shortly introduce some examples. Note that 
the SDL patterns below are not completely specified. We basically summarize a pat- 
tern’s intent and skip the description items explained above. 

• BlockingRequestReply: The BlockingRequestReply pattern introduces a con- 
firmed interaction (two-way handshake) between two given automata. After a trig- 
ger from the embedding context, the first automaton sends a request and is blocked 
until receiving a reply. The request is eventually received by the second automaton, 
which replies and finally releases the first automaton from its waiting state. 

• DynamicEntitySet: Consider a given server entity that provides its service exactly 
one time and terminates thereafter. In order to offer this service several times (e.g., 
to more than one client), the DynamicEntitySet pattern is applied. For each client a 
new server entity is dynamically created by a special entity administrator. Subse- 
quently, the administrator acts as a proxy from the perspective of the clients, which 
forwards service requests to the corresponding server entity. 

• Codex: The Codex pattern provides mechanisms to allow two (or more) entities, 
which interact directly through SDL channels, to cooperate by the means of a given 
communication service. In general, the introduction of a basic service involves 
many specialities. Among others, these are segmentation, reassembly, upgrade of 
basic service quality (e.g., in case of loss, disruption or duplication of messages), 
lower layer connection setup, or routing decisions. The Codex pattern is only con- 
cerned about a minimal subset of these functionalities, namely interfacing with the 
basic service by the means of service primitives. That is, Codex essentially pro- 
vides a mapping from protocol data units to basic service primitives and vice versa. 

2.2. Configuration process 

For the design of SDL protocol specifications we have defined a configuration process 
supporting the reuse of protocol building blocks represented as SDL patterns 
(Figure 1). The configuration process suggests an incremental protocol design, where 




200 



the whole set of communication requirements is first decomposed, i.e., partitioned and 
(where appropriate) simplified. Decomposition classifies as an analysis task that iden- 
tifies separate protocol functionalities. Thereby it is possible to consider a protocol 
functionality under different assumptions. For instance, interaction sequences for con- 
nection establishment are less complex on top of a reliable basic service instead of an 
unreliable basic service. Experience has shown that protocol functionalities can often 
be specified one after the other and - in addition - be stepwise completed (e.g., adapted 
to the non-ideal properties of an underlying basic service). This suggests that we per- 
form an individual development step in order to incorporate an additional protocol 
functionality or relax a corresponding simplification. Thereby each development step 
divides into analysis, design, and validation and yields an executable SDL design 
specification. In the following the different activities within a development step are 
sketched. 

First, an object-oriented analysis of the current protocol functionality is performed. 
This results in an updated analysis model from the previous development step. It is 
suggested to provide an UML [1] object model and an MSC [12] use case model, 
which together identify participating objects and typical interaction scenarios. 

The analysis model is implemented in the following design activity. Here, SDL 
patterns come into place. Starting point is the context SDL specification, i.e., the SDL 
design specification obtained from the previous development step. This may, e.g., be a 
protocol specification, which relies on a reliable basic service. Hence, the design prob- 
lem (stated in the analysis model) could then be to suit the protocol to an unreliable 
basic service. In order to meet the new requirements a number of design steps are per- 
formed that apply separate SDL patterns to the context specification. Note that for 
some design problems the pool of predefined protocol building blocks may not contain 
an adequate solution, so that an ad hoc solution must be found. The selection of an 
SDL pattern is supported by several items of the SDL pattern description template, 
namely intent, motivation, structure, message scenario, semantic properties and coop- 
erative usage. As patterns represent generic design solutions, the corresponding SDL 
fragment has to be adapted in order to seamlessly fit the embedding context. This is 
instructed by the renaming parts of the syntactical embedding rules and the refinement 
rules. The resulting pattern instance finally has to be composed with the embedding 
context, which is prescribed by the composition part of the syntactical embedding rules 
and also by the refinement rules of embedding pattern instances. 

The result of this design activity is an intermediate SDL design specification, 
which is subsequently validated against the analysis use case model. Also, the correct- 
ness of the SDL specification concerning general properties such as freedom from 
deadlocks is checked. If any faults are discovered, a return to one of the previous 
development or design steps is needed (not shown in Figure 1). Otherwise the vali- 
dated specification serves as the context specification for the next development step. If 
all simplifications are eliminated and all requirement subsets are implemented the final 
design specification is given by the validated design specification of the last develop- 
ment step. 
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Figure 1 . Configuration process (excerpt) 

3. Configuring a communication subsystem for CAN 

Controller Area Network (CAN) is a field-bus standard originally developed for 
mobile systems. However, due to exceptional features such as high data rates and fault 
tolerance, CAN became also established in other areas of the field-bus domain [3]. We 
have configured a real-time communication subsystem for CAN using SDL patterns. 
Note that the presentation below follows the configuration process introduced in 
Section 2.2. 
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3. 1 . Communication requirements 

Communication between intelligent sensors, actuators, and controller components 
imposes stringent requirements on timeliness and predictability. Thus CAN employs 
bitwise bus arbitration based on message identifiers to support deterministic media 
access. Message identifiers are to be interpreted as priorities and therefore a global, 
priority-driven scheduling of message transfers is realized. As timeliness and predicta- 
bility strongly depend on worst case traffic load, field-bus installation normally pre- 
cedes a configuration step, where communicating peers as well as traffic loads are 
identified and priorities are assigned accordingly. This step is carried out prior to sys- 
tem operation and works fine for static settings. Nevertheless, the operator or owner of 
a field-bus installation may change communicating devices or applications dynami- 
cally (e.g., in building automation). Though dynamic insertion and removal of com- 
municating devices is generally supported by CAN, timeliness guarantees have to be 
concerned from scratch. 

Therefore a communication subsystem shall be developed on top of CAN that per- 
forms admission control, priority assignment, and traffic policing automatically during 
system operation. This can be seen as a kind of “plug and play” functionality for time- 
liness guarantees, i.e., when, for instance, a new communicating device is inserted, the 
system automatically handles priority assignment with respect to timeliness require- 
ments and under consideration of the already existing traffic load. If there are not 
enough network resources left, the system shall deny additional communicating peers. 

3.2. Decomposition 

The real-time CAN subsystem (Figure 2) is based on a generic QoS architectural 
framework [8]. This framework was also previously instantiated for a real-time com- 
munication subsystem on top of a Token-Ring network [9]. Essentially, the subsystem 
for CAN contains protocol functionalities for initialization of CAN modules (network 
management), resource management, and object-based user communication (e.g., 
access to remote read-only-variables). With the additional simplification that commu- 
nicating peers exchange protocol data units (PDU) directly, i.e., without using an 
underlying basic service, we get the decomposition of Figure 3. The chronological 
order of the performed development steps is also illustrated. 
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3.3. Development steps 

3.3.1. Development step I: Initializing CAN modules, directly connected peers. 

Before communication can start, some CAN modules must be initialized (e.g., pro- 
grams or parameters are downloaded). This process would consume many CAN iden- 
tifiers that are permanently assigned to individual modules. In order to save resources, 
it is suggested to share CAN identifiers for initialization purposes. As a consequence, a 
special control protocol for medium access is needed, which was specified in the first 
development step. The protocol is implemented by a network slave on each CAN mod- 
ule and a central network manager. 

The interaction between the network manager and a network slave is structured 
into different phases. When the slave requests access to the CAN bus, the correspond- 
ing request message contains no data in order to avoid collisions. Thus, the network 
manager must identify the slave before it can be addressed. This is done by a binary 
search that broadcasts identification messages, which contain an interval of valid mod- 
ule identifiers. Only those slaves with a valid module identifier are allowed to reply. 

A slave enters the next phase, when an initialization message with its own module 
identifier is received. As already mentioned, the initialization protocol employs CAN 
identifiers that are shared among all slaves. In order to avoid collisions on the CAN 
bus their use is coordinated by sequencing the initialization phases of individual 
slaves. 

The interaction scenario is implemented by cooperative application of several SDL 
patterns such as SendReceive, BlockingRequestReply or SingleRequestMultipleReplies. 
For instance, the exchange of the request and initialization message follows the Block- 
ingRequestReply pattern, while the binary search for identification of network slaves 
applies SingleRequestMultipleReplies. Because of space limitations we skip further 
details here. 

3.3.2. Development step II: Resource reservation, directly connected peers. 

Before communication can take place a certain amount of network resources must be 
reserved in order to guarantee quality of service (QoS). Figure 4 illustrates the interac- 
tion between a resource slave and the central resource manager. The application asks 
its local resource slave to establish a connection with certain QoS (SPJd.req) and is 
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Figure 3. Decomposition and chronological order of selection 
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Figure 4. Analysis model of development step II (excerpt) 

informed about the result by a corresponding reply (SP_id.conf). Embedded into this 
interaction is a two-way handshake between the slave and the resource manager. The 
slave sends a PDUJdjreserve message with a flow specification containing all rele- 
vant QoS parameters. The resource manager then decides, if the connection will be 
established and assigns unique CAN identifiers to the communication object that will 
be used for data transfer. The identifiers are returned within the PDU_id_reserved 
message. The interaction is realized by a cascaded application of the BlockingRequest- 
Reply pattern. The shaded parts of Figure 5 determine the renamed SDL fragments of 
the embedded pattern instances. 



3.3.3. Development step HI: Object-based communication, directly connected. 

The CAN subsystem supports object-based user communication. That is, a connection 
is established by common access to the same communication object, which, e.g., rep- 
resents a physical quantity or event of a technical process. Access to remote objects is 
realized according to the Client/Server paradigm. Thereby the server side is responsi- 
ble for updating the logical communication object with its physical counterpart, while 
the client side offers remote access. We defined six types of communication objects 
with different access characteristics, such as read-only or write-only objects (Figure 6). 
An object consists of a certain number of clients and servers, which are usually located 
on different nodes. In case of a read-write object (RWobject) the object consists of one 
server and a maximum of one clients (Figure 6). The MSC diagrams describe interac- 
tions between server and client for opening, reading, writing, and closing such an 
object. In the following, we will only consider RWobjects. It should be noted that 
communication based on other objects can be specified independently from each other. 

Design of object-based communication divides into two major steps. At first, it is 
assumed that no more than one server and one client of each type of communication 
object exists per node. Figure 7 shows a possible architecture. Two processes are 
added to the context specification that resulted from development step II (Figure 5), 
one for the client and one for the server of a RWobject. The client is assumed to be 
located on node Coml and the corresponding server on node Com3. For definition of 
the behavior SDL patterns are applied. In the following, we will concentrate on the 
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Figure 6. Analysis model of development step III (excerpt) 

interactions for reading the object. Write access is specified accordingly. It follows 
from the corresponding MSC of Figure 6 that the interactions actually describe three 
cascaded two-way handshakes between the application and RWclient, RWclient and 
RWserver, and finally between RWserver and the application. An SDL pattern generat- 
ing a two-way handshake is BlockingRequestReply. We applied the pattern three times, 
resulting in the chained BlockingRequestReply instances of Figure 7. For the first pat- 
tern instance, which is shaded I only the replier is specified, because the request- 
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DynamicEntitySet 

Figure 8. Design specification of development step 111: Part 2 (excerpt) 

ing application is part of the environment. The requester of the second pattern instance 
(shaded I H is embedded in the first one and defined by the procedure readObject. 

The corresponding replier is located in RWserver and also shaded 1 _J , The 

requester of the third BlockingRequestReply instance is given by the procedure get- 
Value (shaded ). The corresponding replier is part of the application on the 

server side and therefore not explicitly specified. 

In the second major design step we relax the assumption that no more than one 
server or client of each object type be allowed per node. In order to realize this we 
applied the DynamicEntitySet pattern. According to the syntactical embedding rules 
the server and client processes are replaced by process sets with corresponding process 
types. For instance, the process RWserver is replaced by a process type of the same 
name and a corresponding process set RWs (Figure 8), Additionally, an administrator 
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process objectAdmin is introduced, which is responsible for dynamically creating the 
processes, whenever a new object is opened. Subsequently, objectAdmin forwards 
incoming signals to the right instance of the process set. As a consequence, certain sig- 
nal routes must be re-routed, i.e., disconnected from the client and server processes 
and connected to the administrator, which itself must be connected to the process sets. 
For reasons of readability, channels and signal routes are not shown in Figure 8. 

3.3.4. Development step IV: Introducing the CAN basic service. Finally, we re- 
place the direct connections between the communicating peers by the CAN basic serv- 
ice. We therefore have to map PDUs to service primitives offered by CAN. A pattern 
dealing with that problem is Codex (Section 2.1). Its application results in a new SDL 
process for each communication node. We skip further details here. 

4. Generating the implementation 

The design specification must finally be transformed into executable code. Note that 
this is actually not part of the configuration process discussed in Section 2.2, but is 
added to cover the whole development cycle. Implementation can be done manually or 
using a code generator such as the SDT Cadvanced Compiler. For our case study, we 
followed the implementation activity of the SOMT method [10] belonging to the SDT 
development tool set. That is, we first partitioned the SDL design to define the differ- 
ent run-time modules according to the light integration for the real-time operating sys- 
tem QNX. Environment functions are to be implemented, which are responsible for 
interfacing the generated code with its physical environment. Next the implementation 
must be generated using the SDT Cadvanced compiler with its run-time library for 
QNX. As the development tool set does not run under QNX but is implemented on our 
SUN cluster running Solaris, the generated C files must be downloaded and compiled 
on the QNX-PCs. 

4.1. Partitioning and light integration 

Cadvanced allows two types of integration into other operating systems, which mainly 
differ in the way SDL processes are mapped to operating system (OS) processes. The 
tight integration creates an OS process for every SDL process, while the light integra- 
tion creates a single OS process that handles all SDL processes of the SDL partition. 
We decided to use light integration, because at the time of implementation only the 
light integration supported SDL services, which our specification heavily relied on. 

We prepared two different partitions. One that covers the protocol functionalities 
of a slave node (where only network and resource slaves reside, Figure 2) and one for 
the manager node (where additionally the network and resource managers reside. 
Figure 2). The hardware-specific low-level CAN driver was hand-implemented. For 
performance reasons, we also decided to integrate the communication objects 
(Figure 2) into the low-level driver. 
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4.2. Interfacing with the environment 

The generated modules communicate with the environment by the environment func- 
tions xInEnv and xOutEnv. xInEnv provides the functionality to somehow receive 
messages from the environment and transmit the messages as signals to the generated 
module. xOutEnv is the counterpart of xInEnv. It forwards SDL signals from the spec- 
ification to the environment. 

4.2.1. Interface to the low-level driver. The low-level driver provides the functional- 
ity to transmit messages of up to 8 bytes (the maximum length of a CAN frame). A 
second part of the interface relates to the object-based user communication. We focus 
on the basic routines for sending and receiving simple messages, because the gener- 
ated modules only communicate this way. The send routine has three parameters: the 
CAN identifier of the message type, a pointer to a buffer, where the message is stored, 
and the size of the message. The send procedure blocks the calling process until the 
message is delivered. The receive function has the same parameters, while it is non- 
blocking. 

4.2.2. Interface to the applications. The SDL design defines signals to indicate the 
initialization phase and to start communication. To realize this we provide two func- 
tions that block the application until the corresponding signal is received. Addition- 
ally, we define a function that calls the local reservation slave via QNX specific IPC 
mechanisms in order to establish a communication object. 

4.3. Environment functions 

For every signal that enters or leaves the specification, we define a C data type named 
by the signal. For example, for the signal PDLF_iden_rem, specified as 

SIGNAL PDU_iden_rem( integer, integer ) 

we define the data type 

typedef struct { 

char sigtype; 
short inti, int2; 

} PDU_iden_rem_T; 

sigtype is a unique number to identify the signals. Instances of these types are then 
transferred via the CAN bus. 

The environment function xOutEnv, There are two types of signals: the signals that 
have to be transferred via the CAN bus and the signals that realize the communication 
to the application. 

The signals to the low-level driver are implemented by simply allocating an 
instance of the corresponding data type, filling it with the supplied arguments of the 
SDL signal, and sending it by calling the low-level send function. For example, the 
code for the PDU_iden_rem signal looks as follows: 
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} else i£( ( *S) ->NaxneNode PDU_iden_rem ) { 

PDU_iden_rem_T data; 
data.sigtype = SIG_PDU_iden_rem; 

data . inti = ( (yPDef _PDU_iden_rexn * ) ( *S ) ) ->Paraxn2 ; 
data . int2 = ( (yPDef_PDU_iden_rem * ) ( *S) ) ->Param3 ; 
send ( ( ( yPDef _PDU_iden_rem * ) ( * S ) ) - > Paraml . ident , 

/* ID */ &data, sizeo£( data ) ); 

} else i£ ... 

siG_PDu_iden_rem is a unique number for this signal. Expressions such as 
( ( yPDef _PDu_iden_rem * ) ( *s) ) -> Paraml are the Cadvanced standard method to pro- 
vide signal parameters to the environment. 

Communication with the application is realized differently: an application requests 
a service via IPC. When the request is handled, the protocol entity first stores the 
application’s process identifier. If the answer is available, the stored process identifier 
will then be used to reply the answer to the right requester. 

The environment function Jc/fiE/iv. Again there are two types of signals: requests 
from applications and messages from the low-level driver. 

To receive signals from the low-level driver, one has to poll the driver by calling its 
receive function. For every message type there normally exists a different CAN identi- 
fier. So, the xInEnv function calls the receive function sequentially for every possible 
CAN identifier of incoming messages. A typical piece of code looks as follows: 

if( receive ( lD_PDU_iden_rem, data, sizeof (PDU_iden_rem_T) ) > 0 ) { 

S = xGetSignal ( PDU_iden_rem, scNotDefPId, xEnv ) ; 

( (yPDef _PDU_iden_rem *) (S) ) ->Paraml. ident = ID_PDU_iden_rem; 

( (yPDef _PDU_iden_rem *) (S) ) ->Param2 = 

( ( PDU_iden_r em_T * ) ( data ) ) - > int 1 ; 

( ( yPDef _PDU_iden_rem *) (S) )->Param3 = 

( ( PDU_iden_rem_T * ) ( data ) ) - > int2 ; 

SDL_Output( S, xSigPrioPar (xdefaultPrioSignal) (xldNode *)0 ); 

} 

The code inside the if block is the Cadvanced standard method for creating a signal 
instance, defining the parameters, and sending it to the generated module. The code for 
receiving a request from the application is basically the same, only that the message is 
received via the QNX specific “Creceive” call and the signals are differentiated by the 
first byte (the signal identifier sigtype). 

5. Conclusion 

We have presented a case study on the SDL-pattern based configuring of communica- 
tion protocols. SDL patterns characterize as formalized design patterns. However, we 
do not deal with formalizing design patterns in general. That is, instead of formalizing 
reuse concepts we aim to increase reusability within the formal methods area. Thereby 
we naturally benefit from the formal basis provided by SDL. SDL-pattern based proto- 
col configuring leads to formal specifications, which can be further used for validation 
and code generation. This is supported by existing SDL development tools. 
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As compared to SDL specifications that have been developed the usual way, SDL- 
pattern based configuring leads to a more systematic design. This is due to the fact that 
design decisions are well founded and documented. As a consequence, readability of 
the specification and communication among team members is improved. Also confi- 
dence in the correctness of the resulting product increases. It is worth mentioning, that 
a very large portion of the final specification resulted from SDL patterns, where each 
pattern has been applied several times. This provides some evidence that the prede- 
signed patterns have been well chosen. From these observations we infer that our 
approach has the potential of substantially reducing the effort for customizing and 
maintaining communication protocols, which seems to be a prerequisite for develop- 
ing protocols that support applications in the best possible way. Though these state- 
ments result from experience of several test projects, we intend to validate them in a 
stronger sense. In [4] we present an approach for the experimental evaluation of empir- 
ical properties of SDL patterns. 
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Abstract: The traditional approach to automatic verification of value-passing 
processes is to translate them into pure processes, by instantiating input vari- 
ables over all possible values, then submit the resulting pure processes to ver- 
ification tools. The main disadvantage of this approach is that problems with 
infinite value domain can not be dealt with, even if these values are never 
used by the program, as in the case of communication protocols. In this pa- 
per we propose an algorithm which works directly on value-passing processes, 
represented as symbolic transition graphs with assignment. The key idea is to 
instantiate input variables “on-the-fly” , while checking bisimulation, making 
it possible not to store the entire concrete transition system either before or 
during the verification process. As a consequence problems with large, even 
infinite, state spaces can be handled. The algorithm hcis been implemented and 
tested on some typical verification problems. 

1 INTRODUCTION 

The issue addressed in this paper is deciding bisimulation equivalences for 
value-passing concurrent systems. By ‘‘value-passing” we mean data values 
can be transmitted via communication channels between processes running in 
parallel. A typical class of value-passing processes is communication proto- 
cols. A characteristic feature of value-passing processes is that they can per- 



Supported by research grants from the Chinese Academy of Sciences, the National Science 
Foundation of China, and EU KIT 119 project SYMSEM. 




216 



form input and output actions of the forms c?x and c!e, where x is a data 
variable and e a data expression. In contrast, ‘‘pure” processes can only per- 
form atomic actions which essentially allow processes to synchronise with each 
other, instead of exchange data. While algorithms and verification tools for 
pure processes have received considerable attention in the past two decades ( 
[CPS93, SV89, GLZ89], among others), the area of automatic verification of 
value-pcLSsing processes remains almost unexplored. 

The traditional approach to value-passing processes is to translate them into 
pure processes. A key step in such translation is to instantiate input variables 
with all possible values from the data domains which the variables range over. 
For example, the following defines a very simple value-passing process (in CCS 
syntax) 

P = c?x.d\x.P 

where x is a variable of type integer. All P can do is to repeatedly receive an 
integer along channel c then transmit it along channel d. Simple as it looks, so 
far there are no automatic verification tools that can handle it. To use existing 
tools one hcts to first translate P into pure process P': 

P' = . . . + c?-l.d!-l.P' + c?0.d!0.P' + c?l.d!l.P' -h . . . 

which is also beyond the scope of the existing tools because P' has infinitely 
many transitions. 

For value-parsing processes there are two sensible notions of bisimulation, 
namely early and late^ depending on when input variables get instantiated: 
during inferring transitions (early), or during matching for bisimulation (late) ( 
[MPW92, HL95]). The translation-based approach can only handle early bisim- 
ulation. 

In this paper we propose a new approach to value-passing systems with- 
out resorting to such translation. The approach is applicable to both late 
and early bisimulation equivalences. The main novelty is that it combines the 
symbolic framework with “on-the-fiy” instantiation technique. As it has been 
recognised, in many practical value-passing systems (with communication pro- 
tocols in particular) a distinction can often be made between control and data 
variables: the control variables may participate in complicated computations 
affecting the control fiow of the systems, while the data variables just hold 
values “passively” without being tested nor computed. It is often the case that 
control variables take values from finite sets and data variables may assume 
values from infinite domains. For instance, in Alternating Bit Protocols the 
variables for the boolean fiags are control variables, while those holding the 
values being transmitted are data variables. 

We present an algorithm for deciding bisimulation equivalences between such 
value-passing processes. Instead of instantiating input variables before checking 
bisimulation, the algorithm instantiates these variables “on-the-fiy”, during 




217 



the verification process. To see how it works, suppose we are comparing the 
following two processes for bisimulation: 

clx.P and c?y.Q 

where x and y range over {1, 2, 3}. At this stage we know that the two processes 
can only mimic each other when x and y are instantiated with the same value. 
Therefore we can take each value v from the set {1, 2,3} in turn, substituting 
it for X in P and y in Q, then go on to compare P[v/x] and Q[v/y]. There 
are only three pairs of residuals, namely (P[l/x], Q[l/y]), [P[2/x], Q[2/y]) 
and (P[3/x], Q[3/y]) ,to be compared at the next stage. In contrast, the 
translation-based approach would first translate them into 

c?l.P[l/x]-hc?2.P[2/a;]-l-c?3.P[3/a;] and cll.Q[l/x] + c?2.Q[2/x] + c?3.Q[3/x] 

which will then require nine comparisons, with six definitely fail. If x and 
y are data variables, then we adopt the symbolic bisimulation technique by 
instantiating them with the least unused symbolic values. 

To incorporate the on-the-fiy instantiation strategy, as illustrated by the 
above example, the bisimulation checking algorithm should work on the process 
structures in “top-down” fashion. Such an algorithm is also called “on-the- 
fiy” since, when working top-down, it is possible to generate the transition 
graphs piece-by-piece while checking bisimulation, instead of creating the whole 
transition graphs before verification starts [FM91]. For this idea to work the key 
issue is how to efficiently generate transitions “on-the-fiy” at each stage. Direct 
calculating from process syntax using the operational semantics is too costly, 
because each time the same term is encountered the same calculation has to be 
repeated again, and due to recursion such repetition is unavoidable. Using the 
technique of “transition caching” may easy the pain of repeated calculations, 
but the caching table may take up a considerable amount of memory, a resource 
already in short supply. 

The solution proposed in this paper is to use symbolic transition graphs with 
assignment (STGA for short). It is shown in [Lin96] that STGAs correspond 
exactly to regular value-passing processes, and moreover, they are closed under 
parallel composition, hence capable of representing networks of parallel pro- 
cesses. An example STGA is shown in Figure 1.1. As can be seen there, each 
node of a STGA is associated with a set of free data variables, and each edge 
carries three pieces of information: a boolean condition, a multiple assignment 
statement, and an abstract action. A state over a STGA, representing a closed 
term., then consists of a node together with a vector of data assigning values 
to the free variables at the node. These values can then be used to evaluate 
outgoing edges at the node, to produce concrete transitions, in the following 
manner: first the boolean condition is evaluated, if the result is false then this 
edge does not contribute to the real transition from this concrete state; Oth- 
erwise the assignment is evaluated and the result is used to update the data 
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Figure 1.1 Example STGAs 



values, resulting in a new vector of data used to evaluate the action if it is an 
output action (input actions are instantiated on-the-fly as described above). 

STGAs can be generated from process terms using symbolic transition se- 
mantics. For regular processes the sizes of the graphs are linear to the length of 
the terms. In practice both the time used to generate STGAs and the amount 
of memory used to store them are negligible. STGAs can be regarded as “half- 
cooked” syntax: all process dynamics has been represented graphically, while 
data and boolean expressions remain “uncooked” and are carried in the edges. 
The task of deriving transitions from a closed process term is reduced to eval- 
uating outgoing edges from a state. 

A node in a STGA denotes a subterm, and edges leading to a common node 
represent sharing a common substructure. Thus STGAs allow to avoid not 
only direct manipulations on syntactical terms, but also repeated calculations 
due to recurrence of the same term. 

Based on STGAs we have developed an algorithm exploiting the “on-the-fly 
instantiation” idea. Starting from the root nodes of two STGAs with initial 
value vectors, the algorithm tries to build the smallest bisimulation including 
the initial states. At each stage transitions are derived as described above. 
These transitions are then compared for bisimulation. The algorithm only 
stores pairs of state which have been compared. In particular, it does not 
store any concrete transitions (which requires more space than states). As a 
consequence it can handle problems with much larger state spaces than the 
partition algorithm which works on complete transition graphs. The algorithm 
has been implemented and tested on some typical veriflcation problems, and 
the early results are very encouraging. 
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An important issue in designing verification algorithms and tools is the gen- 
eration of informative diagnosis when verification fails, because producing just 
a ‘‘no” answer has little help in debugging the input. As mentioned before it 
is difficult for the the translation-based approach to generate helpful diagnosis 
information, due to the fact that most structuring information presented in 
the original value-passing processes gets lost in the translation. In this respect 
the on-the-fly instantiation algorithm has its advantage. When the two input 
value-passing processes are not bisimilar, it can generate diagnosis information 
in the form of a sequence of state pairs witnessing the failure. As a state con- 
sists of an (open) subterm in the process definition together with a list of values 
for the free data variables of the subterm, it is easy to debug the original design 
using such “high level” diagnosis information. 

The rest of the paper is organised as follows: The notion of symbolic tran- 
sition graphs with assignment is briefly reviewed in the next section. The 
algorithm is then presented in Section 1.4, with its correctness discussed and 
complexity analysed. Section 4 deals with early bisimulation. The paper is 
concluded with Section 5. 

Related work The on-the-fly algorithm for deciding bisimulation for pure 
processes first appeared in [FM91] (to the author’s knowledge). The Mobile 
Workbench also implemented a version of on-the-fly algorithm for open bisim- 
ulation in the context of 7r-calculus [VM94]. The main contribution of the 
present paper is twofold: (1) Lifting the on-the-fly bisimulation checking algo- 
rithm to handle value-passing processes, by instantiating input variables “on- 
the-fly” over symbolic transition graphs with assignment; (2) Combining the 
symbolic bisimulation and “on-the-fly instantiation” techniques so that a class 
of infinite-state problems can be dealt with. 

2 AN ABSTRACT MODEL FOR VALUE-PASSING SYSTEMS 

In this section we will only give a brief and informal introduction to symbolic 
transition graphs with assignment^ and refer the readers to [Lin96] for a detailed 
account on this subject. 

We assume the existence of the following sets: Val (data values), ranged 
over by u,u, . . .; Var (data variables), ranged over by x,y,z,...\ DExp (data 
expressions), ranged over by e, e', . • •; BExp (boolean expressions), ranged overy 

by 6, 6', . • •; Chan (channel names), ranged overy by c, c', We will use the 

customary notations x := e for multiple assignment, \e/x] for substitution, and 
sometime identify x :=e with [e/x]. It is assumed that VarU Val C DExp^ and 
e = e' € BExp for any e, e' ^ DExp. We also assume that data expressions 
are equipped with reasonable notions of free and bound variables, and write 
fv{e)/bv{e) for the sets of free/bound variables of e. 

The set of abstract actions, {r, c?a;,c!e | c G Chan^x G Var^e G DExp}., 
is ranged over by a. The sets of free/bound variables of abstract actions are 
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b,$,T 

m I — > n 
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p\=b 
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c'y 



p\=b 
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Figure 1.2 Late Operational Semantics 

defined by fv{c\e) = /y(e), bv(c?x) = {x}, and fv{a) = bv{a) = 0 for any other 
action a. 

An evaluation p G Eval is a type-respecting mapping from Var to Val and we 
use the standard notation p{x ^ v} to denote the evaluation which differs from 
p only in that it maps x to u. An application of p to a data expression e, denoted 
p(e), always yields a value from Val and similarly for boolean expressions; p{b) 
is either true or false. We will write p \= b to indicate that p{b) = true. If 
a = [e/x] then the application of cr to p is denoted by ap = p{x p(e)}. 

Definition 2.1 A symbolic transition graph with assignments (STGA for 
short) is a rooted directed graph where each node n is a^ssociated with a fi- 
nite set of free variables fv{n) and each edge is labeled by a triple (6, x := e, a). 

A STGA is well-formed if for each edge from n to m, written n it 

holds that /y(6, e) C fv{n),, C and fv{m) C {x} U bv{a). □ 

We will often simply write n m for n and will also omit 0 when 

it is the identity cissignment on fv{n). 

Traditionally (pure) processes are modeled by labeled transition systems 
(LTSs for short) which are directed graphs in which arcs are labeled with 
atomic actions. A vertex in a LTS represents a state and the outgoing arcs 
show the possible actions the process at the state can perform to evolve into 
new states. Existing verification algorithms and automatic tools for process 
algebras are all based on LTSs ([CPS93, SV89, GLZ89]). 

STGAs are graphic representations for value-passing processes, just as tra- 
ditional transition graphs for pure processes. However the STGA represen- 
tations are at a very abstract level as most of the characteristic structures 
of value-passing processes, namely data expressions, boolean conditions and 
input/output actions, are retained in the edges. 

A STGA Q can be ‘‘expanded” into a “partial” concrete labeled transition 
system whose vertices axe pairs of (n, p) with n a node of Q and p an evaluation 
mapping free variables at n to values. Transitions are generated according to 
the operational semantics given in Figure 1.2. Transition systems so gener- 
ated are called “partial” because input actions are not yet instantiated. The 
instantiation will be carried out while graphs are compared for bisimulation. 
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Definition 2.2 A late bisimulation is a symmetric relation R over states such 
that: if (mp,n^) E R then 



c" y 

1. rup implies there exists rtg 



n'^, and for all v E 



Val 



2. for any other actions rUp m'^, implies there exists Ug n'^, and 

im’p,,n'g,) e ij. 

We write rap ^ Ug if there is a late bisimulation R such that {raping) E ii. 
Two graphs ^ and Q' are bisimilar with respect to p and p' if Vp ~ r^, where r 
and are the roots of the two graphs, respectively. □ 



As an example of how to generate symbolic graphs from a process description 
language let us consider regular value-passing CCS given by the following BNF 
grammar: 

t ::= 0 I a.i \ b t \ t -\-t \ P{e) 

where for each process identifier P there is a definition P{x) <;= t which satisfies 
fv{t) C {x} and is guarded^ i.e. every identifier in t is within the scope of an 
action prefixing a. Given a term t in this language a STGA can be generated 
using the following rules: 









true, a h0 ^ , 

I > t t -\-U I > t 



b,0,a f 

u 1 I — y t 






b' 



. bAb',$,a 
t I — > 



t' 



1 t' 



P(e) t' 



P{x) <= t is a. definition 



Two STGAs can be composed using parallel composition operator || and 
restriction operator \. When composing two STGAs it is required that they use 
disjoint name spaces for data variables (so the only way for them to cooperate 
is through communication). The nodes of the parallel composition {Q\\'H)\R^ 
with R a set of channel names, are pairs of those of Q and R with fv{< m > 
) = fv{n) U/t;(m), and the edges are created by the following rules (where the 
symmetric rules of par and com have been omitted): 



par 



b,x:=e,a , 

n I — y n 



b,x 

<n^m > 



e,y,a 



<n\m> 



chan{a) fl iJ = 0 
fv{m) = {y} 



com 



bi ,x '.=ej ,c7z 



n . 



b2,!/:=e2,c!e , 

m 1 — y m 



6 iA 62 ,«,y„ 2 :=ei,e 2 ,e[e 2 /'^,r , , 

<n,m> I — y <n,m > 
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M3{x} M4{x,y} 



N0{} 

C?X' 

Nl{x’} 

c?y’ 




Figure 1.3 



It is easy to see that parallel composition is symmetric and cissociative. This is 
CCS-style “handshaking” communication where communication happens be- 
tween two processes capable of performing complementary (input and output) 
actions, yielding an “invisible” r action. Similarly one can define parallel com- 
position adopting “broadcasting” communication, as in CSP and LOTOS. 

3 THE ALGORITHM 

Given a symbolic graph, a variable is “data-independent” if it does not appear 
in the boolean condition part of any edge label, nor occur as a proper subterm of 
any data expression. Thus data variables are not subject to any operation other 
than assignment. The algorithm presented in this section works on symbolic 
graphs where all variables are either data-independent or with finite domains. 

As observed in [JP92], it is sufficient to “instantiate” each data vari- 
able with a fresh schematic variable when deciding bisimulation. The ap- 
proach proposed in [JP92] is based on the (global) partition algorithm and 
requires a prior construction of complete transition systems. Here we incor- 
porate the idea by adopting the “symbolic bisimulation” technique [HL95]. 
We assume a countable set of “symbolic values” which are totally ordered, 
and the function nextSVal{s^ t) always returns the smallest symbolic value 
that does not appear in the value vectors at states s and t. To illustrate 
how symbolic values are generated, we use the example shown in Figure 1.3 
where all variables are data-independent. Assume the symbolic values are 
• • • (in thsit order). We start with the root nodes. At the state pair 
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(M0{}, N0{}) no symbolic value is used, hence nextSVal{MO{}^ ^^{}) = 
vi which is associated to x and x' . Now at the new state pair 
{Ml{x = ui}, Nl{x' = vi}) we have nextSVal{Ml{x = ui}, Nl{ x' = Ui}) = 
U 2 , SO the next state pair is {M2{x = vi,y = U 2 }, N2{x' = = U 2 }). Af- 

ter the output transitions the new state pair is {M3{x = ui}, N3{y' = U 2 }). 
Since nextSVal{M3{x = vi}, N3{y' = V 2 }) = U 3 , the next state pair is 
{MA{x = ui,y = U 3 }, N3{y' = U 3 }). Passing through the r and output tran- 
sitions we go back to to nodes M3 and N3 again, with the state pair 
[M3{x = U 3 }, N3{y' = U 3 }) (note that x and y got transposed after r move). 
Now we have nextSVal{M3{x = U 3 }, N3{y' = v^}) = vi. 

The algorithm for deciding late bisimulation for symbolic transition graphs 
with assignment is presented in Figure 1.4. It operates on a pair of STGAs Q 
and T-l. The function bisim{s^ t) will always terminate with answer true or false. 
It starts with the initial states pair (s, ^), trying to find the smallest bisimu- 
lation containing the pair by matching transitions from each pair of states it 
reaches. While searching the symbolic graphs, at each pair of nodes the algo- 
rithm uses the values for the state variables to evaluate the edges, according 
to the operational semantics in Figure 1.2, producing concrete transitions and 
next states. The transitions are then matched for bisimulation, and the algo- 
rithm goes on to the new state pairs if the matches are successful. However 
when input edges are encountered the evaluation can not be fully carried out 
because the values for the input variables at the next pair of nodes are not yet 
known. In this case the algorithm behaves as follows: if the input variables 
are data variables then the function nextSVal{s^ t) is called and the returned 
symbolic value is used for the input variables; otherwise each element is taken 
from the value domain associated with the input variables, one by one, to in- 
stantiate the input variables ‘‘on-the-fiy’’ . The algorithm then moves to the 
new states. 

Three auxiliary data structures are used: 

■ NotBisim: List of state pairs which have already been detected as not 
bisimilar. 

■ Visited: List of state pairs which have already been visited. 

■ Assumed: List of state pairs which have already been visited and assumed 
to be bisimilar. 

The core function, match^ is called from function hisinside the main function 
bisim. It performs a depth-first search on the product of the two concrete 
transition graphs which are never fully created. Instead states and transitions 
of the concrete graphs are only generated from the symbolic graphs on-the-fiy, 
when needed. Whenever a new pair of states is encountered it is inserted into 
Visited. If two states fail to match each other’s transitions then they are not 
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bisim[s^ t) = { 

NotBisim := { } 
fun bis{sy t) = { 

Visited := { } 

Assumed := { } 
match{s^ t)} 

} handle Wrong Assumption => bis{s^ t) 
return(6i5(s, t)) 



match{s^ t) = 



Visited := {(s, t)}\J Visited 
b = A matcha{s^ t) 

aG{r,c!v,c?} 



if b = false then { 

NotBisim := {(s, t)} U NotBisim 
if (s, t) G Assumed then raise WrongAssumption} 
return(b) 



a|a€{r,c!t;} }(s? t) — 

for each s for each t - 

b^j — closers ) 
return((A(y6ij)) A (A(y6ij))) 



matched {s^ t) = 

for each s for each t tj 

if X and y are data-independent then 

let 2 : = nextSVal(s^ t) 

bij = close[si[x h-> z\^ tj[y h-)> z\) 

return((A(y A {t\(yy zbij))) 

i j j i 

else for each s for each t tj 

for each v £Val 

hlj = close[si[x u], tj[y u]) 

return((A(y ^A ^^^j))A(A(y 



j v^Val 



A bVj))) 

J t veVal 



c/ose(s, t) = 

if (s, t) G NotBisim then return(/aZse) 
else if (s, t) G Visited then { 

Assumed := {(s, t)}U Assumed 
retmn{true)} 
else return(matc/i(s, t)) 



Figure 1.4 The algorithm 
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bisimilar and the pair is inserted into NotBisiw,. In case the current state pair 
has been visited before, we first check if it is in NotBisim and return false if 
so. Otherwise a loop has been detected and we make assumption that the two 
states are bisimilar, by inserting the pair into Assumed^ and return true. If 
we find the two states are not bisimilar after finishing searching the loop, then 
we know that the assumption is wrong, so we first add the pair into NotBisim 
and then raise the exception Wrong Assumption which forces a rerun of bis^ 
with one piece of new information, namely the two states in this pair are not 
bisimilar. 

The correctness of the algorithm is not difficult to justify. Suppose there 
are k data-independent variables at nodes n and m, then, at most fc + 1 dif- 
ferent schematic values will be used in any state pair (s, t) at (n, m). So 
termination is guaranteed. For these variables the only places they can be 
used are simple output actions of the form c\x where x is data-independent. 
When the algorithm returns true any pair of such output actions successfully 
passed the comparison in match c\ must have their variables instantiated with 
the same schematic value, i.e. they are instantiated at the same time, when the 
two input actions which bind the output variables are compared in match 
Therefore if the input variables are instantiated with the same “real” value, 
the two output actions will still match each other. 

Each call of bis{s^t) performs a depth-first search in the product graph of the 
two concrete transition graphs (which are “generated” piece by piece from the 
symbolic graphs during the search), bis {s,t) is only recalled when the exception 
WrongAssumption has been raised (by match, as explained above), in this case 
the size of NotBisim has been increiased by at least one. Hence bis (s,t) can only 
be called for finitely many times. Therefore bisim{s,t) will always terminate. If 
bisim{s,t) terminates with true, then the set [Visited — NotBisim) constitutes 
a bisimulation containing (s,t): 

Theorem 1 Suppose G and H are finite symbolic graphs with roots n and m 
and initial values p and p' , respectively, and the value domains for the control 
variables are finite. Function bisim[[n, p),[m, p')) always terminates, and if it 
returns true then (n, p) and [m,p') are bisimilar. 

On the other hand, when the algorithm returns false it is not necessary that the 
two graphs are not bisimilar when data-independent variables are interpreted 
over any domain. This can be illustrated by a very simple example: Running 
the algorithm on the two processes 

c7x.cly.d\x.d\y.O and clx.cly.dly.dlx.O 

will return /a/^e, but they are bisiniilar when x, y are only allowed to take value 
from a singleton set. Intuitively this is because the data domain involved does 
not have enough elements to distinguish between different data-independent 
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variables. To give a precise characterisation let DINg be the largest num- 
ber of data-independent variables at any node of graph Q, and DIN the 
minimum of DINg and DIN y,. Then 

Proposition 3.1 If the algorithm returns false then the two input processes, 
with symbolic graphs Q and H, are not bisimilar when their data-independent 
variables take values over any data domain with cardinality no less than 

* 

To see the complexity of the algorithm, let N be the number of nodes in 
the production graph of the two concrete transition graphs. The time required 
for the first call of bis is (at most) 0{N), for the second call is 0(AT — 1), .... 
Hence the worst case complexity of bisim is 0[N (AT — 1) -f ... + 1) = O(iV^). 
However experiences show that the square fact does not appear in practical 
applications: in most cases the algorithm terminates with only one or two calls 
of bis. 

The algorithm has been implemented in Standard ML, and tested on a 
number of examples. In the Appendix is the input file for the alternating-bit 
protocol problem which allows the media to lose data (adapted from an example 
in pure CCS included in the Concurrency Workbench distribution). In the file 
a type named message is defined as a subtype of integer with range 1 ... 10. 
Then all process identifiers, channel names and variables are declared with 
appropriate types (Bool is a built-in type), followed by the conjecture to prove. 
Finally, recursive definitions are provided for the process identifiers (the where 
part). The right hand-side of the conjecture is the specification of the protocol, 
while the left hand-side is the implementation. Both the specification and the 
implementation are compiled into STGAs before subject to the algorithm. The 
STGA for the specification li 2 is only 2 nodes and 2 edges, while the one for the 
implementation has 32 nodes and 80 edges. 

As comparison we also run the same examples using the Concurrency Work- 
bench of North Carolina [CS96] which implements the partition algorithm for 
deciding bisimulation [KS83]. As the examples are written in full CCS Bruns’ 
value-passing front-end [Bru96] is used to translate them into pure CCS before 
fed into the Workbench. Both systems are written in New Jersey ML version 
109, and all results are obtained on a Sparc station with 60MHZ twin-CPU 
and 64MB memory. The first example is the alternating-bit protocol men- 
tioned above. The second is the ‘‘triple-modular redundancy” problem taken 
from [Bru96]. By increasing the sizes of data domains bigger and bigger tran- 
sition graphs can be achieved. When the domains grow up to certain limits 
(100 in the case of alternating-bit protocol and 20 in the case of triple modular 
redundancy problem) the Workbench runs out of memory and stops. On the 
other hand the on-the-fly algorithm can handle much larger domains: 350 for 
the alternating-bit protocol (with 32204 states) and 140 for the triple modular 
redundancy problem (with 140561 states). Moreover, the variables holding the 




227 



messages being transmitted in the alternating-bit protocol are data indepen- 
dent. When it is declared as such (by changing the definition of type message 
to message = data in the input file) the verification takes less than a second to 
finish with answer true^ which means the protocol is correct over even infinite 
data domains. 

When the input processes are not bisimilar, the algorithm terminates with 
false. In this case informative diagnosis information can be easily computed 
from NotBisim. It consists of a sequence of matching transition and ends 
with a pair of states, one of which can do a transition that the other can not. 
For example, if we change the definition of process R(rb) in the AB-protocol 
example in the Appendix to 

R(rb) = tan. sack! (not (rb)) .R(rb) + 

r?(ra,rm).if ra==rb then receive Irm. sack!ra.R(rb) 
else sacklra.R(rb) 

i.e., when the newly received frame has expected boolean fiag (ra==rb), the 
message body is transmitted (receive Irm) and an acknowledge is sent back 
(sack Ira), but the fiag is wrongly remained unswitched (R(rb) instead of 
R(not(rb)) as in the original description). Now feed the revised file to the 
algorithm, we will get the following diagnosis: 

<R(rb) I Mlossy | S (sb) {rb=f alse , sb=f alse} , Spec{}>==send?sm, send?m=> 
<R(rb) I Mlossy | SI (sb , sm) {rb=f alse , sb=f alse , sm=l} , 
receive Im. Spec{m=l}>==receive 1 1 , receive 1 1=> 

<R(rb) iMlossy I if sa==sb then S(not(sb)) else Sl(sb,sm) 

{rb=f alse , sa=f alse , sb=f alse , sm=l} , Spec{}>==send?sm, send?m=> 
<R(rb) IMlossy I SI (sb,sm){rb=f alse ,sb=trne ,sm=l} , 
receive Im. Spec{m=l}> 

now <receive Im. Spec{m=l}>==receive I !=><Spec{}> 

but <R(rb) iMlossyl Sl(sb,sm){rb=false,sb=true,sm=l}> has no 

matching move 

The last two lines read: the specification is at a state where a trans- 

mission is possible (receive II), while the implementation is at the state 
R(rb) I Mlossy I SI (sb , sm) with boolean fiags rb=f alse , sb=trne and can not 
perform such a transition (in fact it is ready to do a send?sm action). 

Such diagnosis information points directly to the source-level process de- 
scription, hence is very helpful for debugging purpose. 

4 THE EARLY CASE 

The bisimulation equivalence discussed above is called ‘date” because input 
variables are instantiated when input actions are matched for bisimulation, 
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instead of when concrete transitions are inferred from process terms (i.e. when 
input edges are evaluated in our case) which takes place before bisimulation 
matching. In late bisimulation each abstract input action of the form clx from 
one process has to be matched by a single corresponding action from the other, 
for all possible values. If this restriction is relaxed by allowing an input action to 
be matched by several input actions, possibly instantiated with different values, 
from the other process, the resulting relation is called ‘‘early bisimulation” . 

Early bisimulation can be obtained by swapping the quantifications “for all 
V € VaF and “there exists” in the first clause of Definition 2.2, so for different 
values the input move from rrip is allowed to be matched by different input 
moved from rig: 



1 . rua 



c(y 



m' , implies for all v 6 Val there exists Ug 



iK'[y^v}ye’[z^v}) ^ R- 
Concerning the algorithm only the matched function needs modifying: 

maic/i^(s, t) = for each s Si 

if X is data-independent then 
let z = nextSVal{s^ t) 

c? y 

for each t tj 

bij = close{si[x z], tj[y z]) 
return((A(V.^V6i,)) A bij))) 

i j 3 i 

else for each v E Val 

ciy 

for each t — ^ tj 

b\’ = close{si[x h-y u], tj[y u]) 
return((A( A (V b^ ))) A (A( A (V6V )))) 

t vEVal j j vEVal i 



such that 



5 CONCLUSIONS 

We have presented new algorithms for deciding both late and early bisimu- 
lation equivalences for value-passing processes. The main novelty of our ap- 
proach is that input actions are instantiated on the fiy, making it possible 
to check bisimulation for value-parsing processes without first expanding them 
into pure processes. Process terms are compiled into symbolic transition graphs 
with assignment During verification concrete transitions are derived from the 
symbolic graphs hence there is no need to store entire concrete transition sys- 
tems, in particular transitions are never stored. The technique of symbolic 
bisimulation has been incorporated so that data-independent variables ranging 
over potentially infinite value domains can also be dealt with. The algorithm 
has been implemented and tested on some examples, and the results show that 
it can handle much larger problems than the translation-based approach. When 
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the input graphs are not bisimilar an informative (‘‘source-level”) diagnosis in- 
formation can be generated, which is very helpful for debugging purpose. 

It should be pointed out that the on-the-fly instantiation method does not 
rely on any particular properties of the data domain involved, hence any tech- 
niques for reducing data domain size can be incorporated. 

As further work we are adapting the “on-the-fly instantiation” algorithm to 
check early and late bisimulations for the 7r-calculus, which can be viewed as 
complementary to the Mobile Workbench [VM94], a veriflcation tool dedicated 
to checking open bisimulation in the 7r-calculus. 
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Appendix: An Example Input File 

type 

message =1 ... 10 

process 

S : Bool 

51 : Bool message 

52 : Bool message 
Mlossy : 

Msafe : 

R : Bool 

Spec : 

channel 

send : message 
receive : message 
r : Bool message 
s : Bool message 
rack : Bool 
sack : Bool 

variable 

sb,sa,rb,ra,ma : Bool 
sm,rm,mm,m : message 
conjecture 

(R(false) I Mlossy | S(false) )\{r,s, rack, sack} = Spec 

where 

S(sb) = send?sm.Sl(sb,sm) 

Sl(sb,sm) = s! (sbjsm) .S2(sb,sm) 

S2(sb,sm) = tau. SI (sb,sm) + rack?sa.(if sa==sb then S(not(sb)) 

else SKsbjSm)) 

R(rb) = tau. sack! (not(rb)) .R(rb) + 

r?(ra,rm).if ra==rb then receive !rm. sack Ira. R(not(rb) ) 
else sacklra.R(rb) 

Mlossy = s?(ma,mm) . (r I (ma,mm) .Mlossy + Mlossy) + 
sack?ma. (rack I ma. Mlossy + Mlossy) 

Spec = send?m. receive !m. Spec 



end 
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Abstract: The paper addresses the problem of solving an equation formulated in terms of the 
input/output finite state machine model. The relation used in equations is 
either FSM equivalence or reduction, i.e. trace inclusion. The composition 
operator corresponds to asynchronous communications between 
nondeterministic input/output machines. These types of FSM equations are 
called asynchronous. A procedure for determining the largest potential 
solution to a given asynchronous equation is proposed. To verify whether or 
not the largest potential solution satisfies the equation, the absence of livelocks 
needs to be established. A solution to the livelock problem is also suggested. 



1. INTRODUCTION 

Designing complex systems usually involves an important step of 
dividing the whole system into a number of separate components which 
interact in some well-defined way. In this context, a question arises how to 
design a component that combined with a known part of the system, called 
the context, satisfies a given overall specification. The problem is also 
known as the problem of submodule construction [Mer83], component 
redesign [Kim72], [Rho91], [Wat93], controller design [Azi95], equation 
solving [Par89], [Lar90], [Qin91], [Che96] or machine factorization 
[Qin91]. This problem has many important applications, ranging from 
hardware optimization to protocol design. In the case of compound systems, 
one may encounter it at the level of validation [Hee95] and test derivation 
[Petr93], [Petr96]. 
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Equation solving has been extensively studied within the process 
algebra, however, not much work has yet been done to solve equations 
formulated in terms of input/output finite state machines, I/O FSMs. In the 
context of hardware optimization [Rho91], one usually assumes strictly 
synchronous communications between components, as several input signals 
should be processed simultaneously, see [Yev91], [Wat93], [Azi95]. In 
many applications, including distributed systems, e.g. protocols, we are 
obliged to consider more loose coiimiunications when components interact 
asynchronously via message buffers or queues. While the problem of 
composing asynchronously communicating I/O FSM has been addressed in a 
number of works in various contexts (mainly within the reachability 
analysis) [Lee93], [Pet93], [Pet94], we are not aware of any result directly 
related to the problem of decomposing a nondeterministic I/O machine into 
asynchronously communicating machines, i.e. equation solving. 

This paper addresses the problem of equation solving for a system of I/O 
possibly nondeterministic FSMs that communicate asynchronously via 
bounded input queues where actions are stored, assuming that the system 
has a single message in transit. Under this assumption, any output of one 
component is immediately consumed by another one as its input, so one may 
say that communications are performed by rendezvous. However, we cannot 
directly use the results obtained in process algebra to solve an equation in 
terms of the FSM model. The problem is that the set of actions of an FSM is 
divided into two sets, inputs and outputs, and any transition is an atomic 
transition labeled by an I/O pair. An I/O FSM can, in fact, be transformed 
into a labeled transition system, but a solution (in trace semantics) to an 
equation can not always be translated back into an I/O FSM. Another 
approach has to be used to ensure that the obtained solution to the equation 
remains in the domain of FO FSMs. In this paper, we propose a procedure 
for determining the largest potential solution to the equation, in the sense 
that any other potential solution is trace included in the obtained machine, 
i.e. it is a reduction of the largest potential solution. A potential solution 
becomes a solution if there are no livelocks when it is combined with the 
given part of the system. When the largest solution to the equation is 
determined an optimal implementation of the component of interest can be 
obtained as an appropriate reduction of the largest solution. For example, an 
optimal implementation should have minimal number of states [Dam94], 
[Wat94] or transitions. In the case where potential solutions exist and the 
largest solution does not, it remains an open question whether a solution to 
the equation exists or not. We demonstrate in this paper that the largest 
solution may sometimes not exist. We also consider an equation where 
composed machines are allowed to communicate internally a certain number 
of times. The idea is to avoid livelocks solving the equation. 
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The paper is organized as follows. In Section 2, we give necessary basic 
notions and define a composition operator for I/O nondeterministic finite 
state machines through a parallel composition operator for labeled transition 
systems. A method for FSM decomposition in terms of equation solving is 
presented in Section 3. In Section 4, we propose some enhancements to our 
method which allow us, solving the equation, to avoid livelocks. Section 5 
presents possible future work. 



2. PRELIMINARIES 

2.1 Finite state machines and labeled transition systems 

A finite state machine (FSM), often simply called a machine throughout 
this paper, is a completely specified, initialized, (possibly nondeterministic) 
observable Mealy machine which can be formally defined as follows. A 
finite state machine is a quintuple (S, X, Y, h, s^), where S is a set of states 
with 5() as the initial state; X - a finite nonempty set of input symbols; Y - a 
finite nonempty set of output symbols; and h - a behavior function h: SxX 
-^p{SxY)\0, where p{SxY) is the powerset of SxY and l{5l 
(5',y)€/i(5,j:)}l<l holds for all {s^)eSxX and all yeY, i.e. the machines 
considered in this paper are observable [Star72]. The machine becomes 
deterministic when l/i(5,x)l=l for all (s,x)eSxX. In a deterministic FSM, 
instead of the behavior function which is required to represent a 
nondeterministic behavior, we use two functions: the next state function, 
and the output function. An FSM B = {S', X, Y', h', Sq) is said to be a 
submachine of an FSM A = (S, X, Y, h, 5^) if S'cS, T'cT and h'{s,x) c h(s,x) 
for all (5,jc)€ S'xX. We extend the behavior function to a function on the set 
X* of all input sequences containing an empty sequence e, i.e., h: 
SxX*-^ p{SxY*)\0. For convenience, we use the same notation h for the 
extended function, as well. Assume h(s,e) = {(5,£)} for all seS, and suppose 
that h{s,p) is already specified. Then h(s,fi)c) = { (s'.yy) I 35"eS [(5",y) 6 
h{s,p) & {s',y) € h{s",x)] }. The function h , often called the next state 
function, is the first projection of h, while h , often called the output 
function of A, is the second projection of h, i.e., h (s,a) = { s' I 3 j8 € F* 
[{s',fi) e h{s,a)] }, h^{s,a) = {p\3s'eS [{s',fi) e h{s,a)] } for all obX*. 

Given alphabets X and Y such that XnF = 0 and sequences a = 
eX* and = yj-.y* e F*, the sequence oGjS = Xjy,...x^y^ is called a trace over 
alphabets X and F. Given state se S of the FSM A = (5, X,Y, h, Sq), the trace 
is called a trace of the FSM A at the state s if ^eh (s,a) or simply a 
trace of the FSM /I if s coincides with the initial state s^. Given an input 
alphabet X and output alphabet F, there exists a special nondeterministic 
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FSM such that any trace over these alphabets is a trace of this machine. We 
call such a machine a chaos machine over alphabets X and Y. In particular, a 
single-state chaos machine is an FSM ({p}, X, Y, H, p), where H(ppc) = 
{p}xyforalljc€X. 

Given two states s of the FSM A and r of the FSM fi= (T, X, Y, H, 
state r is said to be a reduction of s, written r^, if for any input sequence 
the condition H^{r,a) c }i{s,(X) holds; otherwise, r is not a reduction of s. 
States s and r are equivalent states, written s=r, iff 5 <r and r^. On the class 
of deterministic machines, the above relations coincide. 

Given two machines, A and 5, over the same input alphabet, is a 
reduction of A, written if the initial state of B is a reduction of the 
initial state of A. Similarly, the equivalence relation between machines is 
defined. BsA, iff and A^. 

A labeled transition system (LTS) is a quadruple (S, L, T, s^), where S is 
a finite set of states with Sq as the initial state, L is a finite nonempty set of 
observable actions and T c Sx{L(j{r})xS is a transition relation, where teL 
is a nonobservable action. For state se S, we denote in(s) and out(s) subsets 
of actions labeling incoming and outgoing transitions at the state s, 
respectively. As usually, the set of traces of the LTS I is denoted by Tril). 
The LTS I is said to be deterministic if for each state se S, it holds that 
Tg out(s) and for each pair (s,a), se S, ae out{s), there exists at most one state 
s' such that (s,a,s')e T. 

If the set L of actions of the LTS I is partitioned into sets X and Y, L = 
XuT, XnT = 0, then for a sequence trover the alphabet L, the X-projection 
of cr is a sequence obtained by deleting all the actions ye T from the 
sequence cr, and the X-projection of the LTS / [Che96] is an LTS that is 
obtained by hiding all the actions from T in / and determinizing the resulting 
LTS by means of a subset construction [Hop79]. 

Given an FSM A = (S, X, Y, h, 5q), a minimal deterministic LTS I = (Q, 
XuY^ T, qf) is said to correspond to A, if Ttil) = {oWjS I asX* & 
j3e/i (5Q,a)}. We denote an LTS corresponding to A. An LTS 
corresponding to an FSM can be obtained through the following steps: 

- unfold every atomic transition s-xly->s’ into two consecutive transitions 

s-x->s"-y->s'; 

- determinize the obtained LTS by a subset construction; 

- minimize the resulting LTS in trace semantics. 

2.2 Composition of LTSs 

Given two deterministic LTSs C = (Q, L,, H, q^ and Z)= (T, L^, G, t^), 
the composition of C and D is the LTS {QxT, LjULj, F, q^t^, denoted 0\D, 




235 



such that for all states {q,t)eQxT and aeL^vjL^, a triple {qt, a, q't') is a 
transition of the LTS C\\D if one of the following conditions holds 

- aeL^r\L^,{q,a,q%Hmdi{t,a,t%G-, 

- ae L|\L,nL2, t'=t and {q, a, q')e H; 

- ae L2\L^nL2, q -q and (t, a, t')e G. 

We usually consider the initially connected part of the composition and 
trim off states that are not reachable from the initial state and their outgoing 
transitions. 

2.3 Composition of FSMs 




Figure I. A closed system 

We consider a system of two components which are connected as shown 
in Figure 1 and communicate via bounded input queues, where actions are 
stored, assuming that the system has a single message in transit. Let the 
FSM C be defined over alphabets /,, Oj and the FSM B over alphabets /j, O2 
such that = 0 and 0 ^r ^02 = 0 . The following relationships hold 

between the alphabets: X, = /,\ 02 » = ^1^2^ ^2 ~ ^2 = Z = 

/,n(?2 and U = /2nO,. We call symbols of the alphabet X,uX2 = X external 
inputs, symbols of the alphabet Y^uY2 =Y- external outputs, while symbols 
of the alphabet Zul/ - internal actions. We further assume that at least one 
of the sets X,, X2 and at least one of the sets F,, F2 are not empty. Otherwise, 
i.e. when the system has no inputs or no outputs, it can not be represented by 
an FSM. As the system has a single message in transit, at any moment either 
the components exchange messages or one of them communicates with its 
environment which submits a next external input to the system only after the 
system has produced an external output in response to the previous input. In 
other words, we consider a closed system, where the environment is 
described by the LTS with two states (a total chaos system) shown in 
Figure 2 . The behavior of the closed system can be described by the 
composition L^\L^\L^ where and Lg are LTSs corresponding to FSMs C 
andfi. 
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Figure 2. The environment LTS 



If the system LJIL^IIL^ has no livelocks then it can be transformed into an 
FSM over the external inputs X and external outputs Y. The system of the 
FSMs C and B is said to have a livelock w.r.t. an external input sequence 
aeX* if there exists a trace of the LTS L^WLgWL^ such that a is the X- 
projection of /? and the LTS has a path labeled with a containing a cycle 
labeled only with internal actions in ZuU. A livelock is said to be an output 
deadlock if no state 5 with out(s)nY ^0 is reachable from the cycle. The 
system in an output deadlock will never produce an external output even in 
the case of a non-catastrophic interpretation of livelocks when it is assumed 
that a system may get out of a livelock. We assume here a catastrophic 
interpretation of livelocks (a divergent LTS) and leave the composition 
operator for FSMs undefined. Formally, we define the composition operator 
0 for two FSMs as follows. 

Given the LTS L^WLgWL^ without livelocks, we determine (Xuy)- 
projection of the LTS L^IILgllL^ and transform the projection into an FSM, 
denoted COB, by pairing each input with a subsequent output and replacing 
the pair of corresponding transitions by a single transition. We are usually 
interested in the initially connected part of COB, called a composite machine 
of C and B. We keep the same notation COB for a composite machine. 

Compared with LTSs, the definition of the composition operator on 
FSMs is slightly more involved, and opposed to the composition of LTSs, 
the operator is not defined in case of livelocks. Another difference is that the 
environment is required to alternate between inputs and outputs, enabling 
the extraction of the composite FSM COB from the LTS which describes the 
closed system. 

Our definition of the composition operator is, of course, applicable to 
two FSMs communicating without feedback. If, for example, U = 0 or Z = 
0 we have a well-known loop-free composition of FSMs [Cec86]. The case 
when both sets are empty corresponds to a parallel (independent) 
composition of two FSMs. If the sets U, X^ and Tj or Z, X^ and T, are empty 
then the system is a sequential composition of two FSMs studied, e.g. in 
[Kim72], [Petr94]. All these compositions are constrained versions of the 
one considered in this paper. 
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(a) (b) 

Figure 3. An espresso machine, the FSM B (a), and waiter, the FSM C (b) 



Example. Consider a coffee shop which has a machine that produces a 
cup of espresso, it is the FSM C with the inputs Coin, Button, and Hit, and 
the outputs Lamp, Espresso, Idle, shown in Figure 3 (a) and a waiter, the 
FSM B that accepts two inputs, Espresso-please and Money, from the 
environment (customer) and three inputs. Lamp, Espresso and Idle, from the 
coffee machine, the outputs are Espresso-served, Thanks, Sorry, No action 
(to the environment); Coin, Button, Hit (to the espresso machine) or no 
action at all, shown in Figure 3 (b). Note that the waiter behaves 
nondeterministically, when the machine, having accepted a coin, idles 
she/he either apologizes to the customer or hits the machine. The customer 
submits an input Espresso-please or Money after one of the outputs has 
been received from the coffee shop in response to the previous input. Such 
behavior is modeled by the LTS shown in Figure 2. 

The detailed behavior of each machine becomes clear from the LTS 
LJi\Lg\\Lp Figure 4 (a). The obtained LTS has no livelock, so a (composite) 
FSM over the external alphabets can be extracted. The composite FSM COB 
is shown in Figure 4 (b). 




Figure 4. The LTS L^WL^WL^ (a) and the composite FSM COB (b) 



Note that our definition of the composition operator on FSMs essentially 
differs from that used in the area of hardware, see for example, [Wat93], 
[Lin95], [Azi95]. Synchronous circuits are usually constructed in such way 
that several input signals to the same component are synchronized. It means 
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that in the synchronous case, for example, the FSM B in Figure 1 should 
have a compound input alphabet X^kU modeling such synchronization. In 
the asynchronous case, the input alphabet Xi^U corresponds to interleaved, 
i.e. asynchronous, communication considered in our setting. The two 
definitions of the operator come to the same only when each component has 
just one input. Moreover, to exclude oscillations, hardware components 
must participate in just a single interaction in response to external input. 
Opposed to the synchronous case, asynchronously communicating FSMs for 
different external input sequences may involve into a various number of 
internal interactions before one of them produces an external output. As a 
result, no external output might be produced when the system falls into 
livelock. Thus, the problem of livelocks becomes crucial for solving 
equations in the asynchronous case. 



3. FSM DECOMPOSITION 

3.1 Asynchronous FSM equations 

The decomposition problem can be formulated by means of an equation 
in terms of FSMs, similar to that considered within process algebra. Given 
two FSMs, A over alphabets X and Y (the overall specification) and C over 
alphabets XiuZ and Y\KjU (the context), we are required to determine an 
FSM B such that the composition operator 0 is defined for the FSMs C and 
B and a relation, reduction or equivalence, holds for the FSMs COfi and A. 
For nondeterministic FSMs, we have the following three (asynchronous) 
equations 

C0W<A(1); A<C0W(2); C0WsA(3), 

where W is the unknown FSM to be found (if possible). Intuitively, the 
equation, for example, (2) corresponds to the case where the system to be 
designed in given alphabets is allowed to do more, but no less than a given 
specification. 

An FSM B over alphabets Xi^jU and YiuZ is said to be a solution to the 
equation (1), (2) or (3) if 

- the composition operator is defined for the FSMs C and B and 

- COB < A, A < COB, or COB = A, respectively. 

A solution B is called the largest solution to an equation if any solution 
to the equation is a reduction of B. Once the largest solution is found, one 
can then reduce it to a solution that is optimal according to a chosen 
criterion, for example, a machine with a minimal number of states and 
transitions [Dam94], [Wat94]. Similarly, one may define the smallest 
solution to an equation. 
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Generally speaking, one may treat each equation separately. On the other 
hand, given the largest solution to (1) and the smallest solution to (2), the 
product of these solutions is obviously a solution to (3). Hereinafter, we 
consider the equation COW < A only, as it seems most interesting for 
practice. Solving this equation, we solve, in fact, the FSM equation COW = A 
in the deterministic setting. 

3.2 The largest potential solution to the equation COW^ 

Any potential solution to the equation COW < A is a reduction of the 
single-state chaos machine over the alphabets ZjUC and Y^'oZ, denoted Ch. 
This observation suggests that one may solve the equation by deleting 
certain traces from the chaos machine. To this end, we first state the 
following obvious property of the largest solution. 

Proposition. Let an FSM M<Ch be the largest solution to the equation 
COW < A. Then any FSM B<Ch such that at least one of the three following 
conditions is satisfied 

a) COB < A does not hold, 

b) the LTS L^llLgllLg has an output deadlock, 

c) the LTS L(,IILgllLg has a livelock, 
is not a reduction of P. 

The statement indicates the cases when a certain trace of the chaos 
machine should be deleted to reduce it to the largest solution or at least to 
some solution may the largest solution not exist. We will proceed in two 
steps. We first define and construct a so-called largest potential solution by 
weakening the three conditions to the first two and then we check whether 
the composition operator is defined for the context and obtained machine 
(the condition c). The last step can be performed by constructing a 
composite machine, as explained in Section 3.1. This motivates the 
following definition. 

An FSM P<Ch is said to be the largest potential solution to the 
equation COW < A if any FSM B<Ch such that 

a) COB < A does not hold, or 

b) the LTS L^WLgWL^ has an output deadlock 
is not a reduction of P. 

By definition, the largest potential solution P composed with the 
context C has no non-conforming external behavior, but may yet have 
livelock and the composite machine might not be defined. In other words, 
the largest solution (if it exists) is a reduction of the largest potential 
solution, and the latter becomes the largest solution to the equation when the 
composition operator is defined. Then it remains to determine how the 
largest potential solution can be constructed. 




240 



We first present a scheme that generalizes existing procedures for 
equation solving in terms of the LTSs and the FSM (synchronous case) in 
trace semantics. 

Step 1. Based on a chosen definition of the composition operator, derive 
a global machine describing all the sequences of actions that may occur in 
the composition. 

Step 2. Construct the acceptor whose designated dead-state* accepts all 
the traces of the global machine which result in an external behavior not 
conforming to A (according to a given conformance relation). 

Step 3. Construct the projection of the acceptor into the alphabets of 
solutions to the equation. Replace every state of the projection, comprising 
the dead-state, by the dead-state. 

Step 4. Construct the complement of the obtained projection (and in case 
of an FSM equation, convert the obtained complement into an FSM). 

These steps use various procedures depending on the model, 
conformance relation, and composition operator. Adapted to our setting, the 
scheme can be implemented in the following algorithm. 

Algorithm 3.1. Construction of the largest potential solution to the 
equation COW < A. 

Input. The FSM A and context C. 

Output. The largest potential solution [[4,C]] (if it exists). 

Step 1. Transform FSMs C and Ch into corresponding LTSs and 
Construct the LTS L^WL^f^WL^ where is the environment LTS. 

Step 2. 

a) Transform the FSM A into the corresponding LTS L^. Constmct the 
LTS by adding transitions to a designated dead-state labeled with all 
ye (Tuyi)\oMt(5) from each state s of the LTS such that out(s)n(YKjYi) t- 
0 . 

b) Compose the LTSs and and replace all global states of 

the composed LTS, containing a component dead-state, as well as all states 
from which no state s such that out{s)r\Yi^ 0 is reachable, by the (global) 
dead-state. Let be the obtained LTS. 

Step 3. Construct the (X2uCuy2'--^2)-projection of the LTS by a 
subset construction. Replace every state of the (X 2 Uf/uT 2 '^Z)-projection, 
which comprises a component dead-state, by a dead-state. Let L be the 
resulting LTS. 

Step 4. Convert the LTS L into an FSM [A,C\. Complete the FSM [A,C] 
by adding a don’t care state and its incoming transitions from each state 
with an undefined transition for an input in X^U and label them with a 
corresponding input and each output in Y^Z. Delete the dead-state with its 



The dead state in an LTS has no transitions, but in an FSM, it has self-loops labeled with 
each I/O pair over the given alphabets. 
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incoming transitions and consecutively all states whose transition becomes 
undefined for some input until the initial state is deleted or no more state 
can be deleted. In the first case, the equation has no solution and in the 
second case, the largest potential solution [[A,C]] is returned. 

We immediately notice that since the LTS is trace included into the 
LTS Lp one can directly construct L^^IIL^^IIL^ instead of L^IIL^^IILgllL^. We 
first illustrate the algorithm using our example considered above and then 
prove its validity. 





Figure 6. The LTS ^ obtained at Step 2 

Example. We apply the above algorithm to construct a coffee machine 
which can be used in the coffee shop, the FSM A (Figure 4b) with the 
waiter, the FSM C (Figure 3b). Figure 5 shows the LTS corresponding to the 
chaos machine over the alphabets of the coffee machine and the LTS L^, 
where a black hole represents a dead-state. Figure 6 shows the LTS 
obtained at Step 2, where black holes represent a global dead-state. Figure 7 
shows the last intermediate result, the LTS L obtained at Step 3 (a) and the 
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FSM [[A,C\] (b), where dashed lines represent don’t care transitions to a 
don’t care state. The largest potential solution [[A,C]] is a nondeterministic 
machine. Based on this machine, one can construct a few (deterministic) 
coffee machines, including the simplest machine which dispenses a cup of 
espresso once a coin is inserted. 




Figure 7. The LTS L obtained at Step 3 (a) and the FSM [[A,C]] (b) 

Theorem 1. Given two FSMs, A over alphabets X,uX 2 and T,uF 2 and C 
over alphabets X,uZ and Y^^U, if Algorithm 3.1 does not return an FSM 
the equation COW < A has no solution, and if the composition operator is 
defined for the FSMs C and [[A,C]] derived by Algorithm 3.1, then the FSM 
[[A,C]] is the largest solution to COW < A. Moreover, if C0[[A,C]] is not 
equivalent to A then the equation CO IT = A has no solution. 

Proof. According to Algorithm 3.1, a trace jSQyover alphabets X 2 'uU and 
YjuZ is not a trace of the resulting FSM [[A,C]] if and only if one of the 
following conditions holds. 

(1) There exists a trace of the LTS (Step 2b) with the 

(X 2 Uf/uy 2 '^ 2 )-projection resulting in the external behavior different 
from that of A. 

(2) There exists a trace of the LTS (Step 2b) with the 

(X 2 U(/uy 2 uZ)-projection resulting in an output deadlock of the 
composed system (Step 2). 

(3) Trace cannot be a trace of a potential solution (Step 4), because 
there exists veX 2 U(/ such that any trace jSvttyiS over alphabets X 2 UU and 
Y 2 UZ takes the LTS L obtained at Step 3 to the dead-state. 

If Algorithm 3.1 does not return an FSM then there exists a sequence 

U* such that for each trace over alphabets X 2 UU and Y 2 ^^Z one of 
the above conditions 1, 2, or 3 holds while each FSM B over alphabets 
X^U and Y^Z has a trace jSfctyfor an appropriate y^U*.WB has trace j0fcty 
such that condition 3 holds then there exists its prolongation jSv such that for 
each trace jivayS over alphabets X 2 '^U and Y 2 '^Z the condition 1 or 2 holds. 
In other words, without loss of generality, we assume that B has a trace pay 
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for which the condition 1 or 2 holds. In this case, there exists an external 
input sequence a such that the composition of the context C and FSM B 
exhibits the behavior different from that of the FSM A or has an output 
deadlock when a is submitted, i.e. B cannot be a solution to the equation 
COW < A and therefore cannot be a solution to the equation COW = A. 

Suppose now that Algorithm 3.1 returns an FSM [[A,C]]. Trace is 
a trace of [[A,C]] if and only if none of the above conditions 1, 2 and 3 
holds, i.e. only a reduction of [[A,C]] may be a solution to the equations 
COW < A and COW = A. Thus, if the composition operator is defined for the 
FSMs C and [[A,C]] derived by Algorithm 3.1, but C0[[A,C]] = A does not 
hold then the equation COW s A has no solution. On the other hand, any 
reduction of a solution to the equation COW < A is also a solution, i.e. if the 
composition operator is defined for the FSMs C and [[A,C]] derived by 
Algorithm 3.1 then [[A,C]] is the largest solution to the equation C0W< A. 

□ 

If the machine [[A,C]] is not a solution to the equation C0[[A,C]] = A 
then the question as to whether there exists a solution to both equations 
remains open. This is the case in our example, where the composition 
operator is not defined for the FSMs C and [[A,C]] due to livelock. The 
problem is that the waiter may repeatedly hit the coffee machine which 
continues to light the lamp, so the customer may no longer see the waiter 
(state 3 in Figure 7b). 

Concluding this section, we notice that the largest solution to the 
equation COW < A may not exist even when the equation has a largest 
potential solution. Consider the FSMs A and C in Figure 8 (a) and (b). A 
solution to the equation is to be found in the alphabets U = {«,, Uj] and Z = 

The LTS obtained at the second step of Algorithm 3.1, has no dead- 
state (Figure 9). Therefore, the largest potential solution [[A,C]] is a single- 
state chaos machine over the alphabets {«,, U 2 } and {z,, Z 2 }, however, it is 
not a solution to the equation COW < A. At the same time, each FSM trace 
over alphabets X 2 <JU and Y 2 '^Z is a trace of some solution to the equation. 
The FSM [[A,C]] is not a solution to the equation and cannot be reduced 
without losing some solutions. In fact, by direct inspection of the LTS in 
Figure 9, one can verify that an FSM 5 is a solution if and only if the set of 
traces of B includes the regular set 

L = [M2(ZiMi)*Z2V(MiZ2)*«iZi]* 

Apparently, there exists a number of such FSMs. Thus, for each trace 
there exists a solution to the equation COW < A with this trace. 
Consider now trace pay over alphabets X^U and such that j8a)€L. 
Then, by definition of L, the maximal prefix of pay that is in the set L is the 
empty sequence or is terminated with an appropriate zeZ, i.e. the regular set 
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Luipny) ^Iso is in the set of traces of an appropriate FSM that is a solution 
to the equation. 




X\/Ui X2/U2 



CEE=3ID 



(b) 



zi/y2 



Figure 8. The FSMs A (a) and C (b) 




4. AVOIDING LIVELOCKS 

As discussed in the previous section, the largest potential solution is not 
always a solution to the equation due to livelocks. Livelock corresponds to a 
situation when the component and its context in response to external input 
involve into unbounded internal interactions. To avoid livelocks we may 
thus bound the maximal number of internal actions executed by the system 
in response to any external input. One may also impose such a restriction 
attempting at finding a solution such that the response time of the overall 
system does not exceed a certain limit. 

We have to find a solution to the equation COW < A such that in the 
resulting composition, the number of internal actions successively executed 
between any external input and a resulting output never exceeds a given 
threshold /,/>!. We first introduce the /-restricted composition operator 0,. 
Given two FSMs C and B, the FSM C<>fi coincides with the FSM COB if the 
LTS L^IILgllLg has no path labeled with more than I consecutive internal 
actions. Otherwise, i.e. when there exists a path with more than / 
consecutive internal actions, the operator 0, is not defined for the FSMs C 
and B. Next, we demonstrate how the results of Section 3 can be further 
extended to solve the equation C0,W < A. 
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Given two FSMs, A over alphabets X=XiuX 2 and Y=Y\'oY 2 and C over 
alphabets XiuZ and Y\kjU, an FSM B over alphabets X 2 UC/ and Y 2 'oZ is 
said to be a solution to the equation CO, IV < A if the /-restricted composition 
operator is defined for the FSMs C and B and COfi < A. 

The idea behind our approach to solving such an equation is to replace a 
total chaos system over alphabets X 2 UC and Y 2 UZ by a so-called /- 
restricted chaos system that can be obtained from the LTS by 
redirecting internal traces of length exceeding I to a designated dead-state. 
Since the appearance of external output terminates any internal trace we add 
at appropriate states of the LTS corresponding transitions resetting the 
machine back to the initial state. Figure 10 (a) gives an example of an /- 
restricted chaos system for the coffee shop, where 1=2. 

Replacing the LTS by the LTS we can use Algorithm 3.1 to 
find a solution. A small adjustment is required, though. In Step 4, if at state s 
of the LTS L there is a transition labeled with ae U to dead-state then in the 
corresponding FSM, denoted [A,C,/], there is a transition from s to dead- 
state labeled with alb for each be Y 2 ^Z. Such transitions may exist since the 
/-restricted chaos system has transitions to dead-state labeled with internal 
inputs. We denote [[A,C,/]] the resulting machine. 

Theorem 2. Given two FSMs, A and C, and an integer />1, if Algorithm 
3.1 does not return an FSM then the equation < A has no solution. If it 
results in an FSM [[A,C,/]] then [[A,C,/]] is the largest solution to the 
equation C0,W^. 

The proof of the theorem is similar to that of Theorem 1 . As the FSMs C 
and [[A,C,/]] may execute at most / internal actions before producing an 
external output, the composition operator for the FSMs C and [[A,C,/]] is 
always defined; thus, the FSM [[A,C,/]] is the largest solution to the 
equation C0,W^. 

Example. For the coffee shop, we solve the equation C0,1V:^ for 1=2 
and 4. Figure 10 shows the FSM [[A,C,2]] (b) and the FSM [[A,C,4]] (c). 
Note that for /=3, no solution can be found. The submodule has only internal 
inputs and outputs, so the number of internal interactions is always even. 






C,B,H ^ Q L,E,I 



Es,S,T,N 




_ C/E 

dX> CD0^=3O 

B/E 



(a) 



(b) (c) 



Figure 10. The chaos system (a), the FSMs [[A,C,2]] (b) and [[A,C,4]] (c) 
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5. CONCLUSION 

We considered the problem of equation solving for asynchronously 
communicating nondeterministic finite state machines. It was demonstrated 
that opposed to the case of labeled transition systems, equation solving is 
complicated by potential livelocks arising when two machines interact via 
feedback. Due to livelocks, a given equation may have no solution. By the 
same reason, asynchronous equations differ also from synchronous ones 
considered in the context of sequential circuit optimization. An algorithm 
for finding the largest potential solution to the asynchronous equation for 
trace inclusion, i.e. reduction relation, was presented. The largest potential 
solution is the largest solution when the resulting composition has no 
livelock. We also demonstrated that the largest solution may sometimes not 
exist. To resolve the problem of livelocks we proposed to use a special 
chaos system that prevents the composition from falling into livelock by 
imposing a predefined limit on the possible number of interactions inside the 
system. This approach could also be useful when one needs to decompose a 
given system and to keep its response time within a certain bound. The 
results of this paper could be used in a number of applications, such as 
protocol design, controller design, system validation, and test derivation for 
embedded testing. 

Future work in this direction is to generalize the presented approach to 
incompletely specified nondeterministic finite state machines. It would also 
be interesting to study the relation between the complexity of a solution (e.g. 
in terms of the number of transitions) and the number of internal 
interactions. Whether the simplest submodule also needs a minimal number 
of internal interactions in the resulting composition (the system with a 
minimal response time) remains an open question. 
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Abstract 

In spite of the increasingly frequent application of formal verification tools today 
they still are difficult to use for non trivial verification tasks. One reason is that the 
specification languages used by these systems are still quite different than the pro- 
gramming languages designers use. One significant difference is the absence of 
shared variables for synchronous verifiers. Many systems use shared variables in 
their implementation, but most synchronous formal verification tools do not model 
them. Instead the user must use additional variables to maintain the illusion of shared 
memory and model the correct behavior. Unfortunately this can cause a significant 
overhead making the final model much larger than necessary. This work proposes a 
new technique called BDD markings to overcome this problem. BDD markings pro- 
vide a way of keeping track of control flow information and have allowed us to 
implement shared variables in Verus, a synchronous symbolic verifier. Using the new 
method we have been able to verify a variant of a mutual exclusion algorithm used in 
the Mach operating system and to determine the existence of priority inversion in a 
complex real-time system. Priority inversion is a serious and subtle problem that can 
cause real-time systems to fail unexpectedly. Its importance has been highlighted 
recently when it was discovered that priority inversion has caused system shutdowns 
in the Pathfinder spacecraft soon after it started collecting Martian meteorological 
data. This example has been modeled with and without shared variables. The new 
method has allowed verification to be performed up to 10 times faster and using up to 
20 times less memory, demonstrating the efficiency of the technique proposed. 
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Symbolic model checking, synchronization variables, BDD, priority inversion 
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1 Introduction 

Formal verification tools are used more frequently today than ever before and their 
application is increasing even more. However, using such systems is still not as sim- 
ple as using most other tools such as compilers or debuggers. Several reasons make it 
difficult to employ formal verification tools in practice such as the complexity of the 
verification algorithms: for example, careless coding can easily lead to state explo- 
sion. Another reason is that most languages used to model systems are quite different 
than the languages used to implement them. Languages such as Esterel (Berry, 1992), 
Promela (Holzmann, 1996) and Modechart (Jahanian, 1988) have very different syn- 
taxes or semantics than regular programming languages making it difficult to trans- 
late a program from C or a similar language to one of these languages. 

We have previously addressed this problem by defining a new language called 
Verus, integrated into the Verus verification system (Campos, 1996a and 1995c). The 
Verus language is an imperative ‘C-like’ language that has been designed to allow 
straightforward modeling of systems being verified. Using this tool, the system being 
verified is compiled into a state-transition graph. The model uses a discrete model of 
time, in which each transition corresponds to one time unit. A symbolic model 
checker allows the verification of untimed properties expressed in CTL (Clarke, 1986 
and McMillan, 1992) and of time bounded properties using RTCTL model checking 
(Emerson, 1990). Moreover, algorithms derived from symbolic model checking are 
used to compute quantitative information about the model (Campos, 1996a; 1995a 
and 1995c). The information produced allows the user to check the temporal correct- 
ness of the model as well as determine reaction times to events and several other sys- 
tem parameters. This information provides insight into the behavior of the system and 
in many cases it can help identify inefficiencies and suggest optimizations to the 
design. Verus has been used to verify several large complex systems such as 
aircraft (Campos, 1994), robotics (Campos, 1995c) and medical controllers (Campos, 
1995a), as well as the PCI local bus (Campos, 1995b). 

However, a Verus program still behaves quite differently than a similar C program. 
Some differences are needed in order to allow an efficient verification, such as the 
granularity of discrete time used in Verus. Others have been artificially imposed, and 
make programming in Verus more difficult than it should be. One of these differences 
is the lack of shared variables. In Verus, as well as most other synchronous verifica- 
tion tools, multiple processes can be defined. The values of variables can be read by 
all processes, but they are “owned” by one process, that is, variables can be modified 
only by that process. The original release of Verus as well as other verifiers such as 
SMV (McMillan, 1992), CV (Deharbe) and VIS (Bray ton, 1996) have this restriction 
when being used in synchronous mode. This restriction is a significant hurdle for 
many applications because shared variables are extensively used in the actual code. 
Implementing an application that uses shared variables in a system that does not 
allow them is often a complex task. Moreover, it not only increases modeling time but 
also makes the final model much larger, since additional variables (and even pro- 
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cesses) may be needed to model the correct behavior. Shared variables are present in 
asynchronous verifiers, but certain types of systems such as real-time systems cannot 
be easily verified by such tools. 

This work describes a new technique used to implement shared variables in Verus, 
BDD Markings. In the new method BDD variables mark specific points in the control 
flow of the program in order to identify where variable assignments from multiple 
processes can potentially conflict. An important advantage of the method is that once 
the transition relation for the model has been constructed, the variables introduced to 
mark the control flow can be existentially quantified out. In this way the technique 
does not impose an overhead in the model because the new variables are removed 
before the transition relation is constructed. 

BDD markings also allow the determination of which transitions in the state-transi- 
tion graph correspond to given points in the program. This can be used to implement 
a new feature which allows properties to refer directly to specific statements in the 
source code. Properties often refer to points in the control flow where some computa- 
tion is performed. Without BDD markings additional variables have to be declared to 
keep track of this information. These variables make the final model larger and more 
expensive to verify. This overhead can be avoided using the method proposed. 

We have used the new method to verify two examples, a mutual exclusion and the 
priority inversion example described in (Campos, 1996b). The mutual exclusion 
algorithm is particularly appropriate since it relies on shared variables for its correct- 
ness. A variant of this algorithm has been used in the Mach operating system kernel 
(Rashid, 1989). The priority inversion example has previously been implemented 
without shared variables. Its importance has been highlighted recently when it was 
shown that priority inversion caused the sporadic system shutdowns experienced by 
the Pathfinder spacecraft soon after it started collecting Martian meteorological data 
(Wilner, 1997). By revisiting the example we have been able to compare both alterna- 
tives and to see that the shared variable model has performed significantly better. In 
some cases the new model executes 10 times faster using 20 times less memory! 

The paper is organized as follows: we first briefly introduce Verus in section 2. 
Section 3 discusses how a Verus program can be represented using BDDs. In 
section 4 we present BDD markings and in section 5 we show how they can be used 
to implement shared variables. Finally sections 6 and 7 describe the examples imple- 
mented using the new method, and section 8 concludes the paper. 



2 The Verus tool 

Verus is a formal verification tool used to verify finite-state real-time systems that can 
also be applied to systems without real-time constraints. The application being veri- 
fied is modeled in the Verus language and compiled into a state-transition graph using 
symbolic algorithms and represented using BDDs. Model checking and quantitative 
timing algorithms are then applied to the model in order to determine its correctness 
as well as its timing characteristics. Verus is particularly suited to model and verify 
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reactive systems defined by a set of concurrent processes. Even though shared vari- 
ables are used to model communication between processes, this does not restrict the 
application of the tool. Distributed systems can be efficiently verified by modeling 
messages as shared variables and the exchange of messages as changes in the values 
of the corresponding variables. 

The Verus Language 

The main goal of the Verus language is to allow engineers and designers to describe 
real-time systems easily and efficiently. It is an imperative language with a syntax 
resembling that of C. Special primitives are provided for the expression of timing 
aspects such as deadlines, priorities, and time delays. These primitives make timing 
assumptions explicit, leading to clearer and more complete specifications. The data 
types allowed in Verus are fixed-width integer and boolean. Nondeterminism is sup- 
ported, which allows partial specifications to be described. Further details about the 
Verus language including its formal semantics can be found in (Campos, 1996a). 

A fragment of a simple real-time program is used to give an overview of the lan- 
guage. This program implements a solution for the producer-consumer problem by 
bounding the time delays of its processes. The code for the producer process is 
shown below. Variable p is a pointer to the buffer in which data is stored. The pro- 
ducer initializes its pointer p to 0 and the produce variable to false. It then enters 
a nonterminating loop in which items are produced at a certain rate. Line 7 introduces 
a time delay of 3 units, after which an item will be produced. Line 8 marks the pro- 
duction of an item by asserting produce. In line 9 the pointer is updated appropri- 
ately. Line 10 makes sure that the event produce is observed. It is needed because 
the state of a Verus program can only be observed at wait statements, since all other 
statements execute in time zero. This allows a more accurate control of time, elimi- 
nating the possibility of implicit delays influencing verification results. It also gener- 
ates smaller models, since contiguous statements are collapsed into one transition. 

1 producer (p) 

2 { 

3 boolean produce; 

4 p = 0; 

5 produce = false; 

6 while (! stop) { 

7 wait (3 ) ; 

8 produce = true; 

9 p = p + 1; 

10 wait (1) ; 

11 produce = false; 

12 }; 

13 } 



Figure 1 Producer code. 
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16 


consumer (p, c) 


17 


{ 




18 




boolean consume; 


19 




c = 0; 


20 




consume = false; 


21 




while (!stop) { 


22 




wait (1) ; 


23 




if (p != c) { 


24 




consume = true; 


25 




c = c + 1; 


26 




wait (1) ; 


27 




consume = false; 


28 




}; 


29 




}; 


30 


} 





Figure 2 Consumer code 

The consumer code shown above is similar to the producer, the main differences 
are that it must check to be sure that there are items to be consumed (p ! = c), and 
that it takes less time to execute than the producer. The fact that the consumer is faster 
than the producer ensures that the buffer will not overflow, as will be verified later. 

28 mainO 

29 { 

30 int p, c; 

31 

32 process prod producer (p), 

33 cons consumer (p, c) ; 

34 

35 spec MIN [prod. produce, cons . consume] 

36 MAX [prod. produce, cons . consume] 

37 AG (prod. produce -> AF cons . consume) 

38 } 

Figure 3 Producer/consumer main function 

As in the C language, main has a special function in Verus. In this function all pro- 
cesses are instantiated, and global variables can be declared. The variables p and c 
(used as pointers in the buffer) are declared and the producer and consumer pro- 
cesses are instantiated in the main function of the example code. 

Process instantiation in Verus follows a synchronous model. All processes execute 
in lock step, with one step in any process corresponding to one step in the other pro- 
cesses. Asynchronous behavior can be modeled by using stuttering, as described 
in (Campos, 1996a). An implicit instantiation of the main module is assumed, where 
the code in main executes as another synchronous module. 
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Specifications can also follow the code as can be seen. The specifications above 
compute the minimum and maximum time between producing an item and consum- 
ing it, as well as checking that a produce is always followed by a consume. 

CTL and RTCTL Model Checking 

Verus allows the verification of untimed properties expressed as CTL 
formulas (Clarke, 1986 and McMillan 1992) as well as of timed properties expressed 
as RTCTL formulas (Emerson, 1990). CTL formulas allow the verification of proper- 
ties such “/7 will eventually occur”, or “p will never be asserted”. However, it is not 
possible to express bounded properties such as “/? will occur in less than 10ms” 
directly. RTCTL model checking overcomes this restriction by allowing bounds on 
all CTL operators to be specified. 

Quantitative Aigorithms 

Most verification algorithms assume that timing constraints are given explicitly. Typ- 
ically, the designer provides a constraint on response time for some operation, and the 
verifier automatically determines if it is satisfied or not. Unfortunately, these tech- 
niques do not provide any information about how much a system deviates from its 
expected performance, although this information can be extremely useful in fine-tun- 
ing the behavior of the system. 

Verus implements algorithms that determine the minimum and maximum length of 
all paths leading from a set of starting states to a set of final states. It also has algo- 
rithms that calculate the minimum and the maximum number of times a specified 
condition can hold on a path from a set of starting states to a set of final states. Our 
algorithms provide insight into how well a system works, rather than just determining 
whether it works at all. They enable a designer to determine the timing characteristics 
of a complex system given the timing parameters of its components. This information 
is especially useful in the early phases of system design, when it can be used to estab- 
lish how changes in a parameter affect the global system behavior. 

Several types of information can be produced by this method. Response time to 
events is computed by making the set of starting states correspond to the event, and 
the set of final states correspond to the response. Schedulability analysis can be done 
by computing the response time of each process in the system, and comparing it to 
the process deadline. Performance can be determined in a similar way. The algo- 
rithms have been used to verify several real-time and non real-time systems. 



3 FROM A VERUS PROGRAM TO A STATE-TRANSITION GRAPH 



Symbolic Representation 

States are defined by the assignment of values to program variables, where each pos- 
sible assignment to the program variables is a state. Boolean formulas over program 
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variables can be true or not in a given state. The value of a boolean formula in a state 
is obtained by substituting into the formula the values of the variables in that state. In 
general, sets of states can be represented by boolean formulas, where each formula 
represents the set of states in which the formula is true. 

Transitions can also be represented by boolean formulas. A transition s is rep- 
resented using two sets of variables, one for the current state and another for the next 
state. If state s is represented by the formula/^ over the current state variables, and 
state s' is represented by formula /^' over the next state variables, then the transition 
s s' is represented by the formula/^ Af^\ The transition relation of a graph is the 
disjunction of all transitions in the graph. The meaning of the formula representing 
the transition relation is the following: there exists a transition from 5 to s' iff the sub- 
stitution of the variable values for .s in the current state variables and / in the next 
state variables of the transition relation yields true. 

Tracking the Control Flow — Wait Graphs 

The execution of a Verus statement may change the value of one or more program 
variables. In general, it changes a given state .s into another state i-'. Executing a 
sequence of statements in a given state then generates a sequence of states. However, 
in Verus not all of those states are observable. The state of the program can only be 
observed at wait statements. When a wait is executed all changes caused by the 
execution of the block of statements since the previous wait take effect at the same 
time. Transitions in the graph occur only when wait statements are executed. Each 
transition in the graph corresponds to time elapsing by one unit. The statement 
wai t { 1 ) corresponds to one transition in the graph. Longer waits are modeled by a 
sequence of unit transitions. 

It is easier to understand the behavior of a Verus program by concentrating on its 
wait statements. This can be accomplished by translating the program into a wait 
graph. The wait graph corresponding to a Verus program is a graph in which the 
states are the wait statements in the program. It corresponds to an intermediate rep- 
resentation between the Verus program and the corresponding state- transition graph. 
It is used only to illustrate how this translation occurs and is not actually constructed. 




256 



wait(l); 
a = false; 
c = true; 
d = d+l; 
wait(l); 



Figure 4 If Sq is the current state at the first wait, will be the current 

state at the second. 

Transitions between waits are defined as follows. A transition between wait^- 
and wai ty (wai t^* represents the occurrence of a wait statement in the program) 
exists iff waitj can be reached from wait/ in the control flow of the program with- 
out going through intermediate waits. The edges of the wait graph are labelled by a 
relation 7]y between any two states in the state-transition graph. This relation 
describes the state changes caused by the execution of the statements between the 
corresponding waits. It is determined during compilation in the following way: 

• When await statement is parsed an initial relation is set up. It basically states that 
no variables change value (variables only change value when assigned to): (v = v'); 
and that the next transitions that will be generated will start on this wait statement 
(a wait counter variable is introduced to maintain this information): {wc = i), 

• Each statement parsed changes the intermediate relation computed by the previous 
statement according to what the statement does, and produces a new intermediate 
relation. 

The construction of this relation is described in detail in (Campos, 1996a). Intu- 
itively, given two states s and s\ Tyis, s') means that if the execution of the program is 
in wait/ and the current state is s, then there exists a path in the control flow leading 
to waity (without intermediate waits) and the execution of the statements on this 
path will change state s into state s'. The construction of the relation between wait 
statements is complex and its explanation is beyond the scope of this paper. However, 
figure 5 can give an intuition on how these relations are constructed. 




4 BDD MARKINGS 

Let’s assume we want to implement a primitive called assert. The statement 
assert (name) can be inserted at any point in the program. Its semantics corre- 
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spend to creating a variable name in the model such that name is true in exactly those 
states reached immediately after executing the assert statement. 



001 


main ( ) 


002 


{ 


003 


boolean 


004 




005 


wait (1) ; 


006 


a = true 


007 


wait (1) 


008 




009 


}; 




R: {wc = \ A a = a' A b = b') 
Initial relation: 

• starting point is wait 1, 

• no variable changes value. 



R: (wc = I Aa' Ab = b') 
After the assignment: 

• a is true in the next state. 

• b does not change value. 



R:(wc=l A a' Ab = b' A wc'=2) 
At the next wait: 

• ending point is wait 2, 

• R represents all transitions 
from wait 1 to wait 2. 



Figure 5 Constructing the transition relation for a Verus program. 

Implementing assert requires a method to keep track of the control flow of the 
program. This is not always an easy task. It is sometimes difficult to determine if (or 
when) a program executes specific statements. Traditionally a “printf ’ is inserted in 
the program, and if the control flow goes through that point a message shows up on 
the screen. Unfortunately it is not possible to use this technique in Verus, since it does 
not follow a single execution path, but rather explores all of them. A possible solution 
in Verus is to insert a wait statement at the point of interest in the program and 
check to see if that wait statement can be reached. However, this technique affects 
the time delays in the program and can change its behavior. BDD markings provide a 
solution for this problem. A BDD variable is used to mark the transitions that corre- 
spond to the execution of assert in the following way: 

1. Create a BDD variable name and make it false in every transition by default. This 
is accomplished by inserting the clause -nname in the initial transition relation cre- 
ated at the wait statement. 

2. When the statement assert (name) is found, assign the value true to name in the 
current relation, overriding the clause —tname. 

3. Whenever a wait statement is parsed, check to see if there are subsets of the cur- 
rent relation that satisfy name. Those transitions are the ones that traverse assert 
in the source code. 
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Step 2 ensures that all transitions that execute assert are marked with the vari- 
able name. Step 1 guarantees that the transitions that do not execute assert are not 
marked. Step 3 is necessary because transitions in the model are created only at 
wait statements. Before reaching the next wait statement the current relation 
describes a partial transition, whose end state may never be reached because the state- 
ments following assert may change the relation and consequently its end state. So, 
only when reaching the next wait statement we can be sure to have determined a 
transition that executes assert. 

The transitions mentioned in step 3 above represent the execution of assert in 
the program. The subset of R satisfying name at that point, R\ is a formula that 
expresses when assert is traversed. We can then save this formula and associate 
with it the symbol name. Then, the BDD variable name can be quantified out of R\ 
since it is no longer needed. References to name will point to the formula that repre- 
sents it. In this way we can determine when a statement is executed in the program 
without adding extra BDD variables to the model. 

The primitive assert can be implemented in this way, and it can be used to 
express properties about the control flow of the program. This is more efficient than 
the method used otherwise, which is to create additional program variables and 
assign values to them according to the point in the program that is being executed. 
The same method is also used to implement shared variables as described in the next 
section. 



5 IMPLEMENTING SHARED VARIABLES 

In most languages used by synchronous formal verification tools variables are 
“owned” by processes, that is, they can be read by all processes, but can only be 
changed by a single process. However, this is an unrealistic assumption, “shared” 
variables that can be modified by all processes are very frequently used. In fact, many 
applications rely on shared variables in their implementations, for example, to syn- 
chronize processes. But their behavior is difficult to model in symbolic verifiers, 
because concurrent assignments are hard to identify and model correctly using syn- 
chronous composition. Imperative languages in most cases pose yet another problem. 
The reason is that in those languages when a variable is not assigned to it maintains 
its value. Unfortunately this means that there is an implicit assignment in every tran- 
sition that does not mention that variable. Because of this, shared variables are usu- 
ally not modeled in symbolic verifiers. Unfortunately, modeling a system that uses 
shared variables in a language that does not allow them is frequently difficult and 
usually creates a significant overhead because additional variables (and sometimes 
processes) have to be created, making the final model significantly larger than it 
needs to be. 

Both types of conflict described above are present in Verus. The implicit assignment 
problem is caused by the clause v = v' inserted in all transitions that do not assign val- 
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ues to V. It maintains the value of variables that have not been assigned to. However, 
this is no longer valid when using shared variables because a transition that does 
assign a value to v from another process may be executed concurrently, causing a 
conflict. In this case the conflict eliminates the global transition from the transition 
relation, because synchronous composition conjuncts transitions from concurrent 
processes (Campos, 1996a and McMillan 1992), and the conjunction of the formulas 
corresponding to the conflicting assignments yields false. 

To avoid this problem we create a BDD variable assigned^ for each shared variable v. 
This variable is used to mark where assignments to v occur. We proceed by implicitly 
inserting an assert {assigned^) everywhere assignments to v are made. The call to 
assert does not actually exist in the source code, but it is modeled in the compiler. 
At the wait statements we “collect” the transitions that assign values to v by dis- 
juncting them into a partial transition relation TRy. At the same time, we eliminate the 
clause V = v' from all transitions that do not assign values to v. After compiling all 
processes we compute the global transition relation (without the v = v' clause) and in 
the end conjunct the clause (v = v' v TRf) to the global transition relation. This clause 
makes sure that for transitions that do not assign values to v from any process (TRy is 
false) the value of v is maintained (v = v'). For transitions that do assign values to v 
(TRy true), the clause v = v' does not necessarily apply and the new value does not 
conflict with the previous one. 

The method described above implements shared variables in Verus, but it does not 
handle explicit concurrent assignments. They still generate a conflict, eliminating the 
transition from the final model. Consequently, conflicting assignments potentially 
generate states that have no outgoing transition. Verus checks for the presence of 
these states and prints a counterexample showing how conflicting assignments can be 
reached. Racing conditions in the system can be identified this way. 

However, sometimes conflicting assignments are necessary. They can be modeled by 
noticing the following: In most cases when a process writes to a shared variable it 
must foresee the possibility of not succeeding, that is, another process may overwrite 
the value written. We can model this behavior by allowing the possibility of not writ- 
ing to the variable and therefore avoiding the conflict. As shown in figure 6 we can 
model conflicting accesses using a variable random (an extern variable which 
changes value nondeterministically (Campos, 1996a)) to allow the process to avoid 
writing. 



6 EXAMPLE: FAST MUTUAL EXCLUSION 

We have used the method described above to verify Lamport’s fast mutual exclusion 
algorithm (Lamport, 1987) shown in figure 7 below. A variant of this algorithm is 
used in the Mach operating system kernel (Rashid, 1989) to provide mutual exclusion 
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in those systems that have no hardware assistance to this end. In this algorithm two 
variables are used to achieve mutual exclusion. Processes try to write their own value 
on both variables. A process gains access to the mutex area when it succeeds in writ- 
ing to both variables. If it does not succeed, it tries again. The advantage of this algo- 
rithm is that it provides a simple and efficient way of implementing mutual exclusion 
without hardware assistance. The disadvantage is that it may cause starvation. We 
have been able to show that the algorithm is correct and that it indeed can cause star- 
vation, as foreseen. However, we have also been able to determine a property that was 
not described anywhere else. Starvation only occurs when more than two processes 
compete. For a two process system there is no starvation. 

Original program: Verus program: 



while (M != 1) 
M = 1; 
delay 0 ; 

}; 



while (M != 1) { 
if (random) M = 1; 
wait (1) ; 

}; 



Figure 6 Modeling conflicting accesses in Verus 

start: x = i; 

if (y != 0) goto start; 
y = i; 

if (X != i) 

delay ( ) ; 

if (y != i) goto start; 
mutex ( ) ; 
y = 0; 

Figure 7 Lamport’s fast mutual exclusion algorithm 



7 EXAMPLE: PRIORITY INVERSION 

We introduce a hypothetical air-traffic control system to illustrate how priority inver- 
sion can affect a real-time system and cause it to become unschedulable. It concen- 
trates on two of the processes in the system. The first, called sensor, reads airplane 
position data from radars, sets alarms on catastrophic conditions (conditions that can- 
not wait for a detailed analysis), and puts the data into shared memory. The other pro- 
cess, the reporter, reads the data collected by the sensor, and updates the traffic 
controller screens. The sensor is a high priority process since it processes urgent 
events, and must not be blocked by other processes. The reporter on the other hand, is 
a low priority process. Since it doesn’t process urgent events, it may be delayed by 
other tasks. The sensor and the reporter share data, accessed in mutual exclusion. 
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However, this may result in priority inversion, as shown in the following scenario. 
Suppose a third process, called the analyzer is added to the system. This process 
reads data generated by other components of the air-traffic controller and processes it. 
The analyzer is less important than the sensor and has a lower priority. But it is more 
important than the reporter, since urgent conditions may arise as the result of the 
analysis and handling them is more important than updating the screens. Consider 
now the same scenario as above, with the reporter inside the critical section, and the 
sensor waiting on the mutex. At this point, the analyzer starts executing. It will block 
the reporter, since it has higher priority. However, the sensor is waiting for the 
reporter (and therefore also for the analyzer). Since the analyzer doesn’t know the 
relation between the reporter and the sensor, it may execute for an unbounded 
amount of time and delay the sensor indefinitely. If a catastrophic event occurs, it will 
go unnoticed, because the sensor is blocked. The behavior of the system becomes 
unpredictable. This unbounded priority inversion can be seen in figure 8. 

Priority inheritance protocols are one way of preventing unbounded priority inver- 
sions (Rajkumar, 1989). A typical protocol might work in the following manner. As 
soon as a high priority process is blocked by a low priority one, the low priority pro- 
cess is temporarily given the priority of the blocked process. In our example, while 
inside the critical section the sensor is trying to access, the reporter will execute at 
high priority. When the reporter exits the critical section, it will be restored to its 
original priority. In this way, the analyzer will not be able to interrupt the reporter 
when the sensor is waiting. 



Screens Radars 





Figure 8 Unbounded priority inversion 



In the original model mutual exclusion is achieved using an additional process that 
controls the mutual exclusion variable. This process receives requests for mutual 
exclusion, decides among competing requests and grants mutex to one process at a 
time. A high overhead is imposed in this model. In addition to the mutual exclusion 
variable we need one request variable for each process and a new process to control 
the variable. In the new model we only use the mutual exclusion variable, and 
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accesses to mutual exclusion are modeled similarly to figure 6, except that we must 
wait until there is no process in mutex (signalled by M == 0) until we try to write to 
M. Priorities are modeled by forcing high priority processes to write to the variable 
(removing the random clause). In this case conflicts are avoided by the low priority 
process. 

while (M != 1) { 

if (random && M == 0) M = 1; 
wait(l); 

}; 



Figure 9 Accessing shared variables in the priority inversion example. 

This example has been described in (Campos, 1996b). It has originally been imple- 
mented without shared variables. We have been able to reproduce the results previ- 
ously obtained, but with a significantly smaller model. The old model has 20 boolean 
variables more than the new one (a savings of about 30%), and verification has been 
performed up to 10 times faster using up to 20 times less memory. 



8 CONCLUSIONS 

This work describes a new technique for keeping track of control flow information in 
synchronous symbolic verifiers. It has been used to implement shared variables in the 
Verus verification system. We have used the new feature to verify a mutual exclusion 
algorithm and to determine the existence of priority inversion in a real-time system. 
Using shared variables we have been able to perform the verification up to 10 times 
faster and using up to 20 times less memory than the same verification without shared 
variables. These gains demonstrate the efficacy of the new implementation and the 
importance of efficient synchronization primitives in symbolic verifiers. They show 
that the new method can help to make possible the verification of even larger systems 
than previously manageable. 
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Abstract 

Support of nomadic computing on the Internet requires the design of new protocols 
handling issues of user mobility. Our efforts target the universal personal 
computing (UPC) system to provide a continuous personal computing environment 
for mobile users. We selected SDL as a specification language for this new service, 
which allowed us to use Verilog’s SDL tool: ObjectGEODE, for design 
verification. In the paper, we discuss the main principles of UPC, and how the 
simulator and verifier of ObjectGEODE were used during the stepwise system 
design. We illustrate the types of errors detected by the verifier, and show that the 
consistent application of the SDL methodology and the tool has increased our 
confidence in the correctness of our specification. The specification is the basis of 
our further work on UPC prototyping. 



1. Introduction 



Widespread use of laptop, palm-top computers, PDAs and the possibility of 
wireless connection to communication and computer networks anticipate the 
ubiquitous support of nomadic computing on the Internet. One of the main goals of 
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our IWIN (Internetworking Wireless Data Networks for Mobile Computing) project 
involves the design and prototyping of a universal personal computing (UPC) system 
(Li, Y. and Leung, V.C.M., 1997a, b), which allows nomadic users of the Intanet to 
work in thek familiar personal computing environment regardless of their locations, 
or means of access. We envision that the UPC service will be provided at any 
location where Internet access is available, so that users everywhere can benefit from 
it, even during migration, through any available terminals or computers owned by 
the user or provided by the service provider or a third party on location. 

To achieve our goals several new techniques are employed and integrated into our 
system. We selected SDL (Specification and Description Language) of ITU (ITU 
Z.lOO, 1992) and the related methodology to reinforce the design and development 
process with formalism. 

Our design of UPC relies on the following emerging techniques/technologies: 

• The Internet Engineering Task Force approved in October 1996 the IP Mobility 
Support (MIP) protocol (RFC 2002, 1996), which enables terminal mobility on 
the Internet that is transparent to the TCP level. 

• We achieve a homogenous computing environment by applying CORBA 
(Common Object Request Broker Architecture, 1997) technology in UPC. The 
IDL (Interface Definition Language) of CORBA provides a common basis to 
design interchangeable components. CORBA services and facilities are pre- 
defined building blocks for new systems. 

• Java’s (Arnold, K. and Gosling, L, 1997) platform independence allows the 
portability of components. In the case of the CORBA based UPC, the client 
objects are brought to the nomadic user’s site to deliver the familiar computing 
environment. 

We started our work with the investigation of the IP Mobility Support protocol. 
We specified it in SDL. This was also an exercise of the specification of mobility 
with SDL. We reported this work in (Toro, M., 1997). 

Currently we are working on the SDL design of the UPC system. We have chosen 
a stepwise approach: after specifying the basic design, new features are added 
gradually. After each addition or modification of the design we verify the correctness 
of the design. Besides, between the major steps we also validate that the new version 
of our design still satisfies the original requirements. This work essentially differs 
from the previous one, since it is not based on an existing standard or specification. 
For the design of the UPC system we apply Verilog’s SDL tool: ObjectGEODE 
(ObjectGEODE, 1997). Beside SDL, ObjectGEODE suppcxts MSC (Message 
Sequence Chart) of ITU (ITU Z.120, 1992), OMT of (Derr, K.W., 1995), and state 
and entity relationship diagrams to help the design and documentation process. It 
provides tools for the entire system life cycle. We present this work in the following 
sections of the paper. 

Before going to the details of our results we give a short summary on SDL and 
ObjectGEODE, the tool we used in our work. In the third section we discuss the 
UPC system and its specification in SDL. The fourth section brings up the 




269 



verification results and our experience with the tool. We draw our conclusions in the 
fifth section. 



2. SDL and SDL tool support 

SDL is an asynchronous extended finite-state machine based language standardized 
by the ITU for specification and description of communication protocols. It was 
designed for interactive, distributed, real-time systems. 

The most important novelty of the 1992 version of SDL was the introduction of 
object-oriented methodology for the structural elements of the specification. It also 
introduced the remote procedure call as a new way of synchronous communications 
between processes. 

There are several SDL based tools mainly utilized in the telecommunication 
industry. Most of them are in-house products and not commercially available. There 
are two major commercial SDL tools: SDT by Telelogic (Sweden) and 
ObjectGEODE by Verilog (France). None of these tools support the fiill Z.lOO 
standard. Only a third, recently available commercial tool: Cinderella by Cinderella 
(Denmark) claims the full support of the 1992 and 1996 version of the language. 

As we mentioned, in our current work we have employed ObjectGEODE. 

ObjectGEODE 

ObjectGEODE integrates the SDL related methodology with others such as OMT 
(Object Modeling Technique) to assist the protocol life cycle from the very early 
design up to the implementation and conformance testing stages. It offers tools for 
automatic documentation and version maintenance. 

ObjectGEODE provides a graphical user interface for specification using the 
graphical representation of SDL. From the entered specification executable code is 
generated for both simulation/verification, and implementation. The simulator has 
the options of interactive or automatic random simulation. The verifier, which is 
integrated with the simulator, implements breadth-first, depth-first, or supertrace 
reachability analysis, and liveness analysis. To verify certain properties one can 
choose between the construction of observers and the specification of the properties 
in MSC. Afterwards the verifier automatically checks if there is any inconsistency 
between the specified property and the system behavior, or verifies the presence of 
(un)required properties observed by the observer. The verification results are 
presented in several reports: a summary of the detected problems, number of reached 
states and fired transitions, is listed after each run. The transition and state coverage 
reports are presented to the user on demand. During verification problematic 
scenarios are logged, so that one can replay them to analyze the problem. 

MSCs are also used in ObjectGEODE to specify test purposes for conformance test 
suite generation. For each MSC scenario a test case is generated by finding the 
appropriate transitions in the reachability tree and generating the alternative 
transitions and the preambles and postambles. The generated test suite is specified in 
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TTCN-MP (Tree and Tabular Combined Notation, Machine Processable format, IS- 
9646 Part 3, 1992) 



3. Universal Personal Computing 

3. 1. Informal description of UPC 

UPC is designed to provide a transparent continuous computing environment for 
mobile users on the Internet. The key issue of the system is the representation of the 
user’s computing environment and its delivery to the current user location. For 
economic and performance reasons we also require the system to provide the 
requested services locally whenever it is possible or desired by the user. Our design 
includes the case where the terminal or computer through which the user accesses the 
network is a ‘foreign’ one, e.g., one leased from a third party at the visited location. 

As we mentioned in the introduction the emerging CORBA architecture provides 
a virtually uniform platform for object-oriented technology. In addition Java 
provides the portability of the required modules or objects. The CORBA architecture 
allows us to interpret the user’s personal computing environment as the set of objects 
the user usually uses, which we call the user profile. Since the interface between the 
client and the server part of an application is described in standard IDL, any other 
object having the same interface can provide a requested service. This way, certain 
services may be obtained at the user’s actual location through negotiation with the 
local Trader Service, instead of being delivered remotely from the user’s home 
domain. Only if a requested service could not be obtained at a visited location would 
the service be invoked remotely. 

According to the CORBA architecture, the client part of an application delivers 
the familiar user interface to the user. Therefore it is enough to migrate or copy only 
the client part to the user’s location. It is possible that the required client part can 
also be obtained at the visited location, but still the user specific preferences should 
be considered. We define the user profile as the set of clients and the related 
environment objects. Java provides the portability of the client objects. 

Users are identified in the system by their unique logical user identifier (LUI). 
They login to the network by providing this LUI and the password. 

We define a user agent for each user, located in the user’s home domain. It is the 
object in the system to which the LUI is bound, hence it can be found via the 
Naming Service. The user agent authenticates the user whenever it is contacted from 
anywhere on the Internet. The user agent also maintains the user profile and delivers 
it to the current user location after the user has been authorized by the system. Since 
a given terminal may not support every feature specified in a user profile, the 
capabilities of each terminal are described in a terminal profile, which is checked 
against the user profile and only the supported subset of the user profile is 
transmitted to the user location. 
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Since the user agent is always aware of the availability and the current location of 
the user, its functions are extended to include forwarding of incoming messages to 
the user, and acting on the user’s behalf when the user is off-line. 

To maintain a given user-terminal binding and to provide the personal computing 
environment at a terminal, we define the user-terminal agent. It is started up after the 
reception of the user profile, based on the features specified in the profile. The user- 
terminal agent takes care of the user requests to start different services. At such 
request it either starts the negotiation with the local Trader or obtains the required 
object according to the user profile. Since after a migration of the mobile user some 
of the local services may be obsolete, the user-terminal agent maintains also a list of 
these services. Whenever a new location is reached it automatically initiates a new 
negotiation with the new local Trader to replace the obsolete services. CORBA calls 
rely on TCP connections, at which level terminal migration is hidden by the MIP 
protocol. Only the MIP level is aware of whieh subnetwork the mobile node is 
currently attached to, therefore we define a signaling of the motion from the MIP 
level to the user-terminal agent. It is the user-terminal agent’s responsibility to 
decide whether the migration has resulted in a change of the serving object request 
broker (ORB) as well. 

3.2. SDL specification of UPC 

At the UPC level we can distinguish three groups of entities as entities at the user’s 
home domain, entities at the visited domain, and entities in the user’s terminal. We 
group these entities in three blocks. Since we require CORBA in all parts of our 
system, in all of these blocks as a minimum requirement a CORBA Naming Service 
process needs to be defined. In addition, at the terminal and at the visited domain we 
define Trader Services. As part of the system initialization procedure the Naming 
Services exchange their process identifiers and name bindings to become known 
everywhere in the system. 

In CORBA, objects are located on the basis of their object references. For this 
purpose we used the SDL process identifiers in our specification. Therefore a 
Naming Service registers the name and process identifier bindings in a given block, 
and for other Naming Services in the system. The Naming Service process contains 
two states and two procedures with no states. It accepts five input signals. 

The Trader Service, on the other hand, maintains a database of the properties of 
different available services. At request the Trader Service matches them with the 
required service properties and returns the appropriate object, which in our case is a 
process identifier. At the current state, this is only an imaginary process identifier, 
since we have not yet specified the server objects. However, for the comparison of 
each of the defined properties we have to specify the appropriate operators. The 
Trader Service is specified as a one-state process with one procedure. We specify 
only the look up CORBA method; therefore the process has a single valid input 
signal. 

As we mentioned earlier, SDL is an asynchronous language, and the remote 
procedure call has been added lately to provide synehronous communications. 
However, our tool does not support this feature yet. CORBA, on the other hand. 
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defines synchronous and one-way method invocation through the static invocation 
interface, and deferred invocation via the dynamic invocation interface. SDL’s 
asynchronous communication is adequate for the one-way and the deferred 
invocation. To provide synchronous calls in our UPC specification, whenever a 
synchronous invocation is assumed, we introduce a blocking state, from which only 
the inputs received in response to the invocation lead out. Any other input is saved 
for this state. Since we have not specified the object request brokers separately (the 
SDL interpreter provides their functions of signal distribution), these blocking states 
are also guarded with timers from indefinite blocking of the system. 



Beside the CORBA components we have the following processes in each block as 
shown in Figure 1: 




• User’s home: User Agent process 
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• User Terminal: Initial Agent process, User-Terminal Agent process, Application 
Manager process 

• Visited domain: none 

The User Agent process is created at the system start and it remains until system 
termination. Its behavior is straightforward: after initialization, which includes 
registration of the user’s name and process identifier binding with the Naming 
Service, and initialization of the user profile data structure, the User Agent reaches 
the off-line state, and remains there until a login is initiated from the User Terminal. 
The User Agent authenticates the user based on the submitted password. If the 
authentication is successful, the User Agent moves to the online state, where it stays 
until a logout signal is received. In the online state the User Agent can send the user 
profile, update the profile, or deal with exceptions. Accordingly, in the User Agents 
process, two states and three no-state procedures are specified. It accepts five input 
signals. 

The Initial Agent of the User Terminal accepts the login information: the user’s 
LUI and the password. With the LUI, it finds the User Agent through the Naming 
Services, and verifies the user provided password with the User Agent. If the 
authentication is successfiil, it sends the terminal profile to the User Agent and 
receives the user profile. Upon the receipt of the user profile, the Initial Agent 
creates the appropriate User-Terminal Agent for the user, and then terminates. The 
user login and authorization are realized by seven states and six input signals. The 
type of the created User-Terminal Agent depends on the characteristics of the 
terminal and information contained in the user profile. 

The User-Terminal Agent represents a given user-terminal binding. It takes care 
of the actions the user may request: updating the user profile, logout, or starting a 
service. To start up a service, it first checks in the user profile where to look for the 
service. If the service should be started at the user’s home, the User-Terminal Agent 
simply creates a new Application Manager and passes the actual parameters required 
to adjust the service to the user preferences. If the service can be provided locally, it 
checks first with the User Terminal Trader whether the service is available, and if not 
it contacts the Trader of the Visited Domain. After receiving the information about a 
potential server from any of the Traders, this information and the related data from 
the user profile are passed to a newly created Application Manager. Services 
provided by the visited domain are restarted any time the user moves to a new 
domain. The User-Terminal Agent’s functionality is specified via four states and 
seven procedures. Four of the procedures have no states while the rest have 1, 2 and 
3 states. The process accepts three inputs from the user and five inputs from other 
processes of the system. The signaling of a change of the terminal location is 
specified as a spontaneous transition. 

The Application Manager administers a given service for the user. It has two 
states and accepts two inputs sent by the User-Terminal Agent. At service 
termination it terminates and notifies the User-Terminal Agent about the termination. 
The termination is specified as a spontaneous transition in the process. If the user 
requests for an update of the user profile, the User-Terminal Agent collects the 
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necessary information from the Application Managers and sends it to the User 
Agent. At user logout the User-Terminal Agent sends a termination request (one-way 
request) to the Application Managers, notifies the User Agent about the logout, and 
after creation of a new Initial Agent instance the User-Terminal Agent also 
terminates. 

Table 1 summarizes the number of process instances, states, input signals and 
spontaneous transitions in the system. 



Table 1 Summary on the UPC system specification 
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0 


0 


0 


0 


6 


0 
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0 


0 


0 


0 


1 


1 



Although our design would benefit from the object-oriented extension of SDL 
(for example for the processes providing CORBA services), we could not use this 
feature because of restrictions in the tool; i.e., ObjectGEODE does not support 
context parameters or external synonyms. 



4. Specification and verification of UPC in progress 

4. 1, Specification with the assistance of the verifier 

We started the specification of UPC directly with SDL. We did not use other options 
offered by ObjectGEODE, since we already had a basic design at the time the tool 
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was available to us. We use the stepwise approaeh to specifieation, i.e., starting with 
a basic design, to add new features and changes gradually. After each modification 
we verify that the system is free from deadlocks or exceptional situations. The 
following discussion demonstrates this approach. 

As the first sketch of the design in SDL, we specified only the main parts of the 
UPC system and the basic communications between them. SDL allows informal 
parts in the specification: in tasks and decisions. The ObjectGEODE’s simulator 
allows running such specifications, although it obviously cannot interpret the 
informal parts. The simulation at this stage helped us in the general understanding of 
the basic characteristics of the system. The verification could not give any useful 
results at this stage. 

As the next step, we replaced the informal parts related to the user profile, i.e., we 
worked out a detailed data structure and operations on it. This modification allows us 
to use the verifier. A typical report is shown in Table 2(a). 

The verification summary gives information about the type of executed 
verification, the number of reached states and transitions covered, the maximum 
depth reached during the exploration and execution time. The detected errors are 
reported in three categories: an exception refers to a dynamic error during execution; 
a deadlock is a system state when no transition can be fired in the system; a stop 
condition is a condition defined by the user, usually related to a given feature under 
investigation. Additionally the percentages of covered states and transitions are 
given. The liveness mode also reports the number of loops found with no success 
states. This method requires observers to identify the success/error states 
(ObjectGEODE, 1997). 

In the second version of our specification we replaced the signal outputs 
representing synchronous CORBA calls, with the construction of going into a 
blocking state and setting a timer. In the blocking state all but the response for the 
call messages are saved. When we made this change, in one of the processes we 
forgot to specify the transition for the ‘exception’ signal. This immediately resulted 
in the report of Table 2(b) about a deadloek situation in the system. 

Note that the deadlock situation was reported only by the breadth-first analysis. 
Although the depth-first method reported a similar coverage as shown in Table 2(c), 
it did not detect the deadlock for the same specification. 

When we thought that the deadlock was corrected we restarted the verification 
and received the report of Table 2(d) with a number of exceptions (i.e., dynamic 
errors) found. Again only the breath-first analysis reported the exceptions; none of 
the other methods found any error in the specification. 

The dynamic errors were the result of only partially correcting the deadlock, by 
adding the ‘exception’ input in the blocking ‘waitjocation’ state of the User 
Terminal Agent, but forgetting the appropriate value assignment to the ‘local’ 
variable, which contained the reference (process identifier) to the visited domain’s 
Trader Service. Since the ‘exception’ signal meant that there was no Trader available 
at the visited domain, the variable should not be used subsequently for the service 
lookup call. However, because of the obsolete value, this call was issued, and no 
recipient was found in the system. 
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Table 2 Summary of verification results 
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Note that the current version of SDL would not consider this situation an error; 
however ObjectGEODE reports them at verification and interrupts the simulation in 
interactive or random mode. To avoid exceptions and the consequent interruption of 
the simulation in our dynamically changing system configuration, we use timers to 
delay the process termination whenever we expect such a situation. 
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After correction of these errors we ran all verifications again, and no new problem 
was found. However, the request-response pairs could not be matched in the system. 
The message identification was lacking. To correct it, we added a sequence number 
field to the messages, so that an old response could not be accepted any more for a 
newer request. We also guarded all such calls with timers. After all these changes we 
ran the verifications again, and this time the verifier reported no errors by any of the 
methods. We show only the report of the breadth-first analysis in Table 2(e). 

A nice feature of ObjectGEODE is that the new verification results update the 
previous results and so does the simulation. This is important because different 
methods capture different parts of the system state space. This was the reason why 
the depth-first method did not find the deadlock, and this is the explanation of the 
following experiment: 

During the verification we tried different parameter settings for the depth-first 
analysis. Originally we defined the truncation level of the reachability tree at depth 
1000, which normally resulted in a poor state and transition coverage compared to 
runs of the breadth-first analysis, where the number of explored states and transitions 
were similar. By defining the truncation level closer (500, 100, 50) to the reached 
maximum depth of breadth analysis (35), we got similar results with both methods, 
since the smaller truncation level forced the verifier at the depth-first analysis to go 
through the similar part of the reachability tree. The higher numbers of truncation 
kept the analysis in the left most part of the reachability tree. 

Currently we are refining the third version of the UPC specification. To check the 
consistency of a new version of the specification with an older one, we generated a 
number of message sequence charts from the older version and ran the new version 
against them. This serves to verify that a refinement retains the properties of a 
previous version. For such verification ObjectGEODE generates observers from a 
MSC document. We found no inconsistency between the different versions of the 
design so far. 

4.2. State and transition coverage 

We ran the verifications without any limitation set on the exploration size, so all the 
runs used the maximum memory available, and stopped when they reached this limit. 
Eventually, as seen in Table 2(e), we reached approximately half a million system 
states, and one and a half million transitions were investigated. There would be no 
other way of verifying such a number of states and transitions except with the use of 
an appropriate tool. 

One can see from the report in Table 2, that there were still uncovered states and 
transitions. To find out more about these we used the state and the transition 
coverage reports of ObjectGEODE. 

The state coverage report lists all the states for all the processes and procedures 
and for each of them gives the number of hits cumulatively for all instances. Beside 
the process and procedure state symbols (unlike in the verification results, in the 
coverage report the data part is not considered) the tool takes into account the 
process and procedure start symbols as states. The coverage rate is calculated as the 
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proportion of states visited at least once to the number of states of the process or 
procedure. Table 3 presents an excerpt of a state coverage report. 

Table 3 Excerpt from state coverage report 

states coverage of userhomelnamingservice : rate 66.67 
start : 1 
listen : 72731 
wait : 0 

states coverage of userhome!namingservice!find : rate 100.00 
start : 64512 

states coverage of useragent : rate 100.00 
start : 1 
online : 87694 
offline : 34967 

states coverage of check_profile : rate 100.00 
start : 95 

states coverage of update_profile : rate 100.00 
start : 87336 

states coverage of useragent !create_profile : rate 100.00 
start : 29491 



From the state coverage list we can easily determine the states which have not 
been checked during the verification. In this case the unchecked states are the states 
of the Naming Services, which have been introduced for compatibility with the 
CORBA standard but are not used by the UPC system. In other words, we have 
covered all the reachable states in the system; hence there is no need of further 
verification from this point of view. 

The transition coverage report presents the cumulative statistics on transitions 
(state-input pair) fired in each process and procedure. It also gives the proportion of 
transitions fired at least once to the number of transitions in the process or procedure. 
Table 4 shows an example of transition coverage report. 

One can see that ObjectGEODE lists as transitions the procedure calls and 
automatically adds a ‘discard’ transition for each process or procedure, representing 
the SDL implicit transition (i.e., an input for which there is no transition specified 
explicitly so it is discarded in a given state). The tool also adds a time-out counter for 
each timer of a process. These automatic additions and the timer handling are the 
features of ObjectGEODE we found arguable. 

The simulator and the verifier of ObjectGEODE handle differently the signals 
entered from the system environment (composing the feed-list) and the internal 
signals with respect to the time-out signals. If a time-out signal’s alternative is from 
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the feed-list (i.e., from the environment), the time-out signal is encountered as an 
alternative, otherwise not. As a result, transitions which are triggered by time-outs 
and have alternative internal signals are never executed during automatic 
verification, which in our case includes most of the time-outs in the system. We 
could check these transitions only by interactive simulation, i.e., by stepping forward 
the system’s timer, so the time-out would happen, and the alternative became 
available. At this point, when we had to do the job manually, we really appreciated 
the convenience of the automatic verification for all the other cases. 

Table 4 Excerpt from transition coverage report 

transitions coverage of userhomelnamingservice: rate 50.00 
start: 9336 

from_wait_input_location: 0 
from_wait_input_exeeption: 0 
from_waitJnput_reply: 0 
from_listen_input_unbind: 5465 
from_listenJnput_bind: 29692 
from_listen_input_exception: 0 
from_listen_input_resolve: 10540 
calLdelete: 5465 
call_find_l: 29692 
calLfind_2: 10540 
call_find_3: 0 
discard: 0 
timeout_reply: 0 



Furthermore, in the current way of interpretation, a time-out would be 
encountered several times at the calculation of the transition coverage as the report of 
Table 4 shows. It would be taken into account once when the specification 
encounters the time-out signal (e.g. from_wait_input_reply), and once at the 
automatically added ‘timeout_reply’ transition. 

We also debate with the suitability of two other automatically added items on the 
report, i.e., the introduced ‘discard’ transition and the procedure calls (e.g. 
call_find_l). In the case of the discard transition, our problem is that the tool does 
not check whether or not all of the inputs are handled explicitly by the specification. 
This addition is Justified only when some of the inputs are not handled by the 
specification. Otherwise this addition falsifies the transition coverage rate. It is 
further questionable whether it is better to add a ‘discard’ transition for each state or 
state-input pair, or one for the whole process. They will give different coverage rates. 
In any case, the main issue for the designer is to be aware of the fact that a signal has 
been discarded by the system via an implicit transition. For this purpose any of the 
solutions is helpful. Regarding the inclusion of the procedure calls in the process 
transition coverage again the question is whether or not this figure is important for 
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the designer. Since the transition coverage is listed for the procedures similarly as for 
the processes we do not see the need of the inclusion of these calls. In contrary, 
encountering each of them as a transition corrupt the transition coverage report for 
the caller process or procedure. In reality these calls might not represent different 
transitions at all; for example if they were subsequent calls in the same transition. 
They might not represent different state transitions at all, if the procedures contain no 
states, or on the opposite, they might hide several transitions if a procedure contains 
a state with multiple possible inputs. 

It is important to be aware of how ObjectGEODE interprets these characteristics, 
so one can compare the reported results with others calculated by another approach. 

In our case after analysing the results and taking into account all these, it can be 
seen that we have reached the maximum possible transition coverage for the 
specification. The recalculated state coverage after excluding the start transitions was 
96.27. Uncovered states were only those in the Naming Service introduced for 
compatibility. The transition coverage was 73.11 after excluding the procedure calls, 
time-out counters and ‘discard’ transitions where the automaton was fully specified. 
Uncovered transitions were related to the uncovered states and timers or error 
handling, which would not happen during automatic verification. They had to be 
checked manually. 



5. Conclusions 

We have found very useful and effective the application and the assistance of 
ObjectGEODE in the design of UPC. During this work the static and dynamic 
checkers of the tool brought our attention to any possible inconsistency in our 
specification. In many cases these were only warnings, but many times they helped 
to spot errors, which would be extremely difficult to find without this assistance. 
Most of the errors were result of inattentiveness. It was trivial to correct them, as we 
showed in our example, once we knew that there was an error in our specification. 
However, even at the early stage of the work it was difficult to take into account all 
possible states and behaviors of our system even with the help of the simulator, 
because of its distributed and interactive feature. The simulation and the subsequent 
verification gave us confidence of the correctness and completeness of the 
specification. 

Selecting a standard language like SDL gave us the advantage of: 

• The application of the methodology worked out for the language based on the 
experience of many researchers and technicians around the world, and 

• A powerful tool, ObjectGEODE, which was introduced to the market several 
years ago and is gradually finding its way to acceptance by the industry. 

In spite of some short-comings, ObjectGEODE’ s capabilities are overwhelming 
in comparison with the in house tools we used earlier. We are convinced that to 
design a complex system, which is typical for modern communication systems, such 
design help and assistance as provided by ObjectGEODE are imperative from the 
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very beginning of the work. ObjectGEODE is also easy to learn and use. There was 
some awkwardness in the earlier version of the tool, but most of it was corrected in 
the newversion 3.2. The new HTML based manual is more convenient, though 
addition of some more links would be a great help for the user. 

We are continuing our work on the UPC system with further refinements of the 
specification. Some of the features we plan to add include allowing multiple user- 
terminal bindings, specification of the type hierarchy of the user-terminal agents, and 
refinement of the application manager. 

Beside the specification, we are also working on prototyping the system, based on 
the specification. This work was started before the final specification, since the 
prototype will not implement all the options specified in the final version of the 
design. At the same time, practical implementation issues bring up new questions 
which help us in the refinement of the specification. For prototyping we could use 
the C code generated by the design tool. Unfortunately, as we mentioned earlier, 
many of the system components require Java implementation for portability, which 
is not yet supported in ObjectGEODE or any other SDL based tool we know. 
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Abstract: In December 1996, a project called LVARTS was finished and delivered to the 

ESA. The goal was to validate a real system, namely ATAC, an ADA co- 
processor chip, running on a real board. The system was big enough to develop 
specific methodologies and tools, which are described in this paper. LOTOS 
was chosen to formally specify ATAC. The formal specification was used to 
produce test cases that were executed against the chip, after a completion 
process to obtain executable test cases. 



1. INTRODUCTION 

This paper is based on the experience gained from the Project “LOTOS 
Validation of an ADA Runtime System”, ESA contract No. 
10797/94/NL/FM(SC), carried out by CRISA, GMV and DIT-UPM (hereby, 
the Consortium) and started in April 1994 and finished in December 1996. 

The objective was to apply rigorous validation strategies on a Complex 
Hardware System (the ADA Tasking Co-processor, ATAC) based on Formal 
Description Techniques (FDTs). This implies the definition and developing 
of theoretical and practical procedures, concepts, tools and whatever was 
needed for validating the real, big, complex system working in a real 
environment. 
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The project was divided in four major phases, as the chip was available 
and it was not needed to develop it: 

1 . Production of the User Requirement Document (URD) of AT AC. 

2. Specification of ATAC in LOTOS, including the validation of the 
formal specification against the URD. 

3. To develop a Validation Environment and to derive Conformance 
Test Cases (through a Conformance Test Tool also generated within 
the project) from the formal specification. 

4. To validate a real ATAC implementation that consisted of a board 
using the MA31750 |i.P and the co-processor ATAC. 

This paper focused on point 3, as it was intended by the Consortium that 
both the methodology and the tools were as general as possible, so it could 
be applied to other systems, even using other FDTs. The article layout is as 
follows: section 2 describes different Validation strategies considered by the 
Consortium and their uses applying Formal Methods are looked at. Section 3 
focuses on the Validation Environment, comprising hardware and software. 
In Section 4, conclusions are exposed. 



2. VALIDATION METHODOLOGY 

Current day conformance testing is based on the standard ISO-9646 "OSI 
Conformance Testing Methodology and Framework" [ISO:9646]. ISO-9646 
is a five-part standard that defines a methodology and framework for 
conformance testing, mainly oriented to protocols. However, much of that 
standard applies to conformance of any product, not specifically 
communication protocols. 

2.1 Validation and Conformance Testing 

Validation and Verification (V&V) is a collection of analysis and 
techniques activities across the full life cycle [Wall89] of a product, oriented 
to determine that it performs its intended functions correctly, to ensure that it 
performs no unintended functions, and to measure its quality and reliability. 

Verification involves evaluating the product during each life-cycle phase 
to ensure that it meets the requirements set forth in the previous phase. It 
answers the question “are we constructing the product correctly?” Validation 
involves testing the product against its requirements. It tries to answer “Are 
we constructing the correct product?” 

A particular case of validation is when a formal specification of a system 
is available. In that case, the implementation of the system is tested against 
that specification called Reference Specification. Conformance is to 
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establish if an implementation conforms to its specification. Let define 
Conformance formally in next section. 

Let us define Conformance formally. It is said that an implementation 1 
conforms to a specification S if and only if 1) for any behavior imposed by 
S, I is able to perform it, and 2) for any behavior rejected by I, it is foreseen 
in S this rejection. In other words, the implementation only behaves as 
indicated by S, and it is only able to reject something if it is considered in the 
specification. This definition includes several aspects: 

1) Conformance testing only takes into account allowed behavior in the 
specification. 

2) The specification only imposes some minimum conditions and 
behavior. 

3) The specification may have optional aspects: there is no obligation to 
follow them, but if it is the case, the implementation should follow 
the specification. 

Usually, it is not possible to test conformance at 100%. The problem may 
be mathematically exposed, but undecidable in practice: all possible 
behaviors, and data values should be tested. However both are usually 
infinite, so it should be fixed a sensible, reachable limit, that defines certain 
degree of tested or covered specification. These are coverage metrics, 
defined in the field of conformance against what part of the specification has 
been tested. The more tests executed on the product, higher values of 
coverage will be obtained. 

The use of formal techniques in the conformance process implies a 
number of advantages, discussed in next section. For the conformance 
process, it supposes that a formal, computer-treated specification is 
available, from which test cases may be automatically generated. 
Conformance process is represented in figure 1 . 

The first step is to generate a test suite for the product. This is the test 
generation or derivation phase. The test suite is divided in test groups, 
organized hierarchically, divided functionally. A single test is called test 
cases, composed by test events. Test cases are organized by test purposes. 

A test purpose is a description of the goal of the test precisely defined, 
oriented to a conformance requirement, accordingly to the system 
specification. 

Test cases are functionally composed by a preamble, a test body and a 
postamble. The preamble is a preliminary phase that drives the 
Implementation Under Test (lUT) into the desired state in which the test will 
start. In simple tests, this preamble is empty. The test body is the sequence of 
test events that ensures the accomplishment of the test purposes. The 
postamble is the sequence of actions that conduct the specification to a stable 
state. Sometimes it is as simple as a reset button. 
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The second step in the conformance process is to make the test cases able 
to be executed. This is called Test Case implementation, and the result is to 
obtain the Executable Test Cases (ETC), in order to be applied to the lUT. 
ETCs are particular for every product. In this paper, we will use Test 
Procedure (TProc) as a synonymous for ETC. 




Figure 1: Conformance Process 



The last phase is Test Execution. The ETCs are executed on the lUT. The 
result is a conformance verdict: PASS, if the product conforms to the 
specification, FAIL if the product does not conforms and INCONCLUSIVE, 
if neither a PASS or FAIL verdict may be emitted. 
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2.2 Formal Description Techniques 

The growing complexity of real systems nowadays has originated the 
need for well-defined, complete, unambiguous and precise specifications. 
From this point Formal Description Techniques (FDTs) appeared to cover 
these problems. By using these techniques, systems are described with 
languages that have a formal syntax and semantics. FDTs are based on well- 
defined mathematical models, which allows a formal analysis of the system. 
Currently, there exists FDTs based on EFSM (Extended Finite State 
Machine) as SDL, with a wide impact on industry and based on Process 
Algebra as LOTOS, with a growing field of application and use. 

LOTOS (Language Of Temporal Ordering Specification) was designed 
for describing open distributed systems, and is applied to concurrent and/or 
distributed systems in general. The basis of LOTOS is the description of a 
system by means of the definition of the timing relation, which constitute the 
observable behavior of a system. In LOTOS, a system may be specified by 
the composition of the different subcomponents that concurrently performs 
the desired functionality. In that sense, LOTOS is able to capture the 
architectural composition of the system. 

2.3 Different approaches 

There are a number of theories that pretend to generate, more or less 
automatically, test cases from a formal specification written in LOTOS. In 
this section, an overview of them is presented. Also a couple of test 
execution methods may be identified, and here they are discussed. 

Brinksma's Canonical Tester [Bri89] uses a process model (failure trees) 
that identifies processes test equivalents. This work includes an algorithm to 
develop such Canonical Tester. The Canonical Tester is the tree of all test 
traces for the specification. Although it model a lot of basic concepts, as 
testing relations, etc, the Canonical Tester is complete, in the sense of it test 
all the behavior at once. This makes impossible to develop the 
Correspondent ETS and there is no possibility of organization by 
requirements, purposes, etc. As exhaustive testing is not possible in practice, 
this approach should be given up. 

Wezeman [Wez88], starting from Brinksma's Canonical Tester, 
developed another method called CO-OP. It tries to produce tests step by 
step, by Identifying COmpulsory and Optional set of events. However, the 
method ends obtaining the Canonical Tester, result that validates the process 
but makes unfeasible for industrial application. 

In 1991, Robles, Manas and Huecas [Rob90] developed a Test 
Conformance Derivation and Execution methodology based on ISO-9646. 
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The key concept is the combination of Test Purposes and the Formal 
Specification, which allows driving a trace extraction process by test 
purposes. These traces are completed lately to become full Test Cases. This 
is called Test Case Completion, and its goal is to deal with the 
undeterminism contained in the specification. ATS are specified in a formal, 
abstract language (LOTOS in this case). ETS have been particularized for 
certain lUT, taking into account implementation details. 
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Figure 2: Tester Functional Organization 



The advantages of this approach are: 

1 . Test Cases are generated automatically from the formal specification. 

2. Test Cases are validated by construction. 

3. Test Cases are formally defined. 

4. Test Purposes are validated by composition with the Formal 
Specification. 

5. Verdict Assignment may be automatically performed with the 
appropriate execution method. 

Test Purposes are defined with respect to the formal specification, so 
means to identify elements within the specification should be provided. 
These elements can be actions and states. However, systems are usually 
conceived as state machines, extended or not, and this is the usual 
information used by humans. On the other hand, the same action may be 
performed in different states. Hence, a state identification mechanism should 
be provided, namely State Labeling. Relevant states are identified by 
assigning an unique label in the whole specification. These labels are special 
gates that the Test Executor will not consider as events to be sent to or to be 
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received from the lUT. However, real events may be used to identify states if 
there is a biunique relation between a state and the event. This reduces the 
work of labeling a specification, making Test Purposes more expressive. 

The execution of Test Case on a real implementation is shown 
schematically in figure 2. In this figure, the main concept is the interrelation 
between the Test Executor and the real implementation. These points 
separate the abstract, formal world, written in LOTOS with a specific 
semantic and the real interface with the lUT. This gap should be fulfilled 
with Adaptation Software, particular for each lUT. The requirements for this 
Adaptation Software are described in section 4.3. 

Test Executor should decide which event should be imposed (controlled) 
to the lUT and which ones should be waited for (observed). The point in 
which this interaction takes place is called PCO (Point of Control and 
Observation). These PCOs may be physically separated from the lUT, and it 
is usually the case. In the ATAC project, as described below, the 
Implementation Access Points (lAPs) are inside a breadboard, connected 
with the Test Executor remotely. Hence, the Adaptation Software should 
take care also about delays in the communication with the lUT, so timeouts 
should be assigned to each event of the specification. 

2.4 Selected methodology 

The generation of Test Case from a LOTOS specification usually 
implies, for realistic systems, that the Test Case generator (CTG) should deal 
with indeterminism. This indeterminism is presented in several ways: 
different path (traces) to reach the same state, open (symbolic) values 
handled by the specification, unsolved predicates and/or guards, partial 
functions, etc. Using a specific methodology, or introducing more details of 
the system may solve some of them. The result is that a wider, longer tree 
than needed is obtained as seed for Test Cases. For large systems, 
performance problems will arise if no shortening is introduced. 

However, the indeterminism due to open values still remains when the 
Test Case is generated. Usually, an intermediate phase of Test 
Parameterization is needed. 

In the ATAC project, as a solution both to solve the indeterminism and to 
improve performances, the lUT runs in parallel with the CTG, thus 
providing the needed values for the Test Cases and narrowing the expanded 
tree obtained from the specification. 

Among the advantages, this composition is able to deal with any kind of 
indeterminism. Also a great performance improvement is expected. The 
main drawbacks are that it tests a specific lUT, without previous test 
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generation phase. Anyway, the results are logged, so they can be used as 
seed for test case completion. 

2.5 Coverage 

In this section, the coverage metric for LVARTS project is described. For 
a comparison among different metrics, please refer to [Hue95]. The metric 
should satisfy the need of tester specificators and developers in order to stop 
the test generation process or to decide if still more test are needed. The 
metric is also used to check the marginal coverage, i.e., the value increasing 
in a test battery when a new test is added. 
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Figure 3: Coverage Metric w.r.t. the Product (a) and w.r.t. the Specification (b) 

Commonly, coverage refers to which parts of a system have been tested. 
In Conformance Testing, the lUT is seen as a black box, so coverage metric 
should not (and could not) refer to any concept related with the 
implementation. However, a third element exists, the Reference 
Specification, written in some FDT, LOTOS for this project. The metrics 
defined within this project (and the chosen one, described below), take 
advantage of it, referring of which part of the specification has been tested in 
the lUT. Hence, when a test is executed, this metric quantifies how much of 
the specification has been exercised. 

Besides, metric coverage can be calculated against the Reference 
Specification before executing the test, measuring the power of test cases. 
This value is called a priori measurement. On the other hand, when the test is 
executed not all of the possibilities are explored, resulting in some reduced 
values for coverage: it is the a posteriori value, which suits the common 
concept of execution coverage. 

In an ideal world, every possible behaviour and every possible data value 
would be tested. However, both behaviour and data are often infinite objects, 
making unfeasible to exercise every trace of the system. Therefore, some 
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reachable and desirable limit should be fixed, limit which allow us to get 
some decent confidentiality on the tests. Arbitrarily, some finite number is 
regarded as 100% coverage. Then, we start at 0% value, and as more and 
more test are executed on the implementation, the coverage grows until 
eventually it reaches the 100% coverage. If such is the case, no further test is 
needed, up to the criterion used. Obviously, a congruent coverage metric 
would accomplish that: 0 < C < 1 00 for certain value of coverage for any 
test case. 

2.5.1 Event components coverage 

The semantic richness of LOTOS is the synchronization among 
processes, which compounds actions by means of involving one or more 
action denotation: the multi way rendez-vous. 

Unfortunately, the number of components of a multi way rendez-vous 
cannot be statically determined: constraints may be generated dynamically. 
It is however true that potential components are finite, and may be 
determined statically. However, it is quite sensible to treat compound event 
as set of events (repetition is meaningless in coverage), which drive to a 
finite count. The sense of such affirmation is that repetition of a behaviour 
does not increase marginal coverage. In other words, confidence is not 
gained as the same event is repeated more and more: repetition of the same 
action denotation does not exercise new parts of the specification. 

Even this finite measure may be difficult to count. If we want to know 
the different combinations of actions that may compose events, [symbolic] 
execution may be needed. As an alternative, we may extract the single action 
denotations in the text (as in action coverage), and then consider every 
possible combination of those, without repetition, and satisfying LOTOS 
rule for sort matching. In general, not all of these combinations are possible 
as not all action denotations are found in the same scope. Even with that, not 
all possible combinations are generated in a given compositional 
architecture. And more, there is an structural defect, since several important 
constructions become collapsed: 

g pattern ; g pattern 
g pattern i I g pattern 
g pattern [] g pattern 
g pattern >> g pattern 

That means that we are not only interested in the difference of every 
action denotation: if the specifier considered relevant to repeat some action 
denotation the coverage criteria should not hide such differences. That is 
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easily achieved by means of considering the relative “position” of the 
events'. 

To summarize, this coverage metric is able: 

• To check all possible synchronizations in a specification, and only 
those belonging to it, so the a priori and a posteriori values may 
coincide. 

• To deal with different ways to compound an action. 

• To deal with infinite behaviour due to the data types, as only the sort 
is considered relevant in the action. 

• To manage infinite and recursive behaviours by means of avoiding 
repetitive components. 

2.5.2 Formal Definition of the event component coverage 

The event component coverage requires deriving all possible 
combination of events in order to set the 100% limit. Basically, it consists of 
the structural analysis of a LOTOS specification, which allows computing 
such set. This analysis will be used also to compute the coverage of a test 
execution, considering the offered actions belonging to the combination set. 

First, let show a formal definition of the metric. The usual notation of 
Labeled Transition System is used [Bri86]. The following characteristics 
should be included in the definition: 

• Unique identification of single event on the text of the specification. 

• Characterization of the possible combination with the gate name and 
the associated sort list (from the experiments). 

The first point is solved with the unique identification of the 
subexpressions in the specification. The second one is solved with an 
adequate representation of the combinations. As said above, this 
representation will be the gate name and the sort names of each action 
denotation. 

Let see the following definitions: 

2.5.2.1 Unique identification of subexpressions 

A behaviour expression may be an action subexpression or the 
composition of behaviour with any LOTOS operator. For every action 
subexpression, an unique identifier may be assigned. In LOTOS, the 
following constructions are considered action denotations: internal actions 
(i), termination actions (exit) and other actions (gates with experiments, with 
or without predicates). 

Some of these expressions may be identical. A possible way to assign the 
unique identifier is to denotate with numbers the position of a subexpression 



1 An alternative way is to identify every LOTOS subexpression in the text. 
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in a global behaviour. The objective of this unique identifier is to 
differentiate actions whose syntactic compositions are not the same. 

2.5.2.2 Composition Representation 

A composition is defined asgl!^'’ f'l' , where their components are: 

• g: the gate on which the synchronization occurs, with 
( gL G U ), and G is the set of gates defined in the specification. 

• <S|, ... ,s„>: The list of sorts from the experiment list, if exists. It 
should be pointed out that in this way actual values are ignored, as 
the only interest is in the data types. 

• {id|, ... , idm} : The set of unique identifier of each component in the 
external action. As it is a set, repetitions of the same event 
participating in an action are collapsed, representing the fact of it is 
not counted for the coverage the repetition of a event more than 
once. 

2.5.2.3 Composition Set of a Behaviour Expression 

The Composition Set of a behaviour expression are all the different 
compositions that the behaviour expression may offer. It is defined as: 

PS(B) = {o\3(7,B';B = B'1 B'-o ^ } 



2.5.2.4 Stable state 

Let be a specification S, and a state Bl. B1 is a stable state if and only if 
any action after it, is observable. 

2.5.2.5 Identifiable state 

Let be a specification S, the initial state Bo, a state B], and a a sequence 
of actions. Bi is an identifiable state if and only if every application of A to 
the initial state Bo ends in Bj. 

VnlB„=5o=cr? ? B„ ..B, 



2.S.2.6 Identifiable trace 

A trace c is identifiable in a behaviour expression B, and it is denoted as 
cr id B if and only if: 
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if5 = <7? ? 

V0i,02Such5 = cT ? Q\,B = g1 Qi f Q\..Q2 

Intuitively, a trace is identifiable if the specification ends in a unique 
state after its execution. In other words, the observations of such trace 
always reach the same state in the specification. 

2.5.2.1 Terminating trace 

A trace a is terminating in a behaviour expression B and it is denoted as 
O’ ter B if and only if: 



if 5 = O ? ? 

a such B = o 1 -a ♦ 

Intuitively, a trace is terminating when, if accepted in a behaviour 
expression, it may not show more actions. Now it is possible to establish 
when a test may be assigned a coverage value: 

2.5.2.8 Measurable Tests 

Test Cases should satisfy some conditions so coverage values can be 
assigned to them. There are two causes for it: 1) The test execution may end 
up without identification of a unique trace on the specification. This happens 
when the specification may reach different states from the same trace. 2) 
There may be sequences of actions that reach non-identifiable states in the 
specification, so coverage cannot be assigned accurately. 

Therefore, every ending of a Test Case must reach an identifiable and 
stable state within the specification. On the other hand, coverage is assigned 
to the whole Test Case (a priori) or to a finished execution (a posteriori). 
Therefore, only those traces that reaches the end of a Test Case are taken 
into account to compute the coverage value. A measurable test on a 
specification (S) will be a behaviour expression T such: 

VctL Tr(T)if(7terT? aidS 
where Tr(T) is the set of traces belonging to T. 

2.5.2.9 Assignment of Coverage Value 

Let be r a measurable test over a specification S. The coverage value of T 
would be^: 



^ Card stands for the set cardinality. 
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M(T,S) 



Card(PS(T || ^)) 
Card(PS(S)) 



2.5.2.10 Suitability for LVARTS 

Event component coverage is the closest concept to the offers that a 
specification may show. In other words, it tries to reflect how many offers 
have been executed among all possible ones in the system, without repeating 
behaviour. 

The number of possible combinations is rather difficult to calculate: a 
specific semantic analysis of the behaviour is needed. This analysis should 
expand the behaviour tree and calculate the possible offers. That drives to 
the state explosion problem. 

However, it is possible to establish the theoretical limit of combinations: 
all possible combinations of action denotations (see previous paragraph). 
This limit should be done taking into account the LOTOS rules for offer 
matching: the same gate name and the same sort lisf . This limit is an upper 
bound for the number of real combinations that may exist in a specification. 
The conclusion is that this limit is suitable to be considered the coverage 
limit, knowing that it may not be reached as non-existence combinations 
may be generated. However, it is known that some of such non-existence 
combinations would be generated. 

For test execution, it should be recorded the combinations of each 
performed action. This task is reduced to log the line number of all action 
denotations producing such action. As line numbers identify uniquely the 
action denotations, there is no need (maybe for debugging purposes) of 
registering the gate names and associated sort lists. LOLA provides the line 
numbers of the components of an offer. 

Once the set of line numbers is generated (as a set, without duplicates), 
its cardinal divided by the number of combinations calculated as the limit, is 
the coverage figure for the test execution. 



3. VALIDATION ENVIRONMENT DEVELOPMENT 

As stated, the proposed approach provides a methodology with the 
objective of obtaining and executing a set of relevant ATCs. The described 
methodology is supported by different tools that cover the different phases of 



^ These lists are ordered. Besides, remember that specific values are not considered in 
behaviour coverage. 
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the testing process: 1) Formal Specification of the system, 2) Test Cases and 
Test Procedures generation and 3) Execution of the Test Procedures 

The Validation Environment (VE) is composed of those tools and is 
conceived to be as general as possible for any lUT. 

3.1 Functional Architecture 

Following the discussion in section 2.1, the Validation Environment may 
be logically divided into four main components (see figure 4): 1) LOTOS 
transformational toolset 2) Conformance Tests Generator (CTG) 3) Test 
Executor (TEX) and 4) Adaptation Software (ASW). 




The transformational environment assists the user in the definition of the 
formal specification of the lUT and acts as the interface of the rest of the 
system with the formal specification. The CTG component produces 
Abstract Test Cases instantiated into Test Procedures with relevant data. The 
TEX interprets the test procedures and exercises the SUT with the actions in 
those test procedures. 

All these components are implementation independent. They may be 
used to test any complex system. However these components are not enough 
to execute the test procedures. The specification is an abstract representation 
of the lUT. The interactions at specification gates must be translated into 
actions over the system interfaces. This is the role of the last component 
included in the Validation Environment: the ASW, which may be considered 
part of the SUT, and acts as the interface between the Test Executor and the 
lUT. 
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3.2 Transformational Environment 

The validation of the LOTOS specification against its informal 
requirements requires a Transformational Environment (TE). Among other 
analysis, the following are performed; searching patter of actions, exploding 
the specification up to certain depth, proving that the specification shows a 
property, removing loops of internal actions, etc. LOLA was used for these 
objectives. 

3.3 Conformance Test Generator 

The purpose of Conformance Test Generator (CTG) is to derive from 
system specifications conformance test. In principle the CTG design was 
conceived for any LOTOS specification. Nevertheless, some assumptions 
must be followed when specifying the system. 

The first approach was to take as much advantage as possible of the 
capability provided by the LOTOS tools to get into the specification. A 
specification is managed by the tools as a labeled transition system. Such a 
system is similar to an Extended Finite States Machine (EFSM). Obviously, 
the intention was to produce a subset of traces directly related with the 
objective of the Test Purpose. The use of symbolic values produced at 
generation time reduces the explosion in the number of states among other 
problems. 

In the phase of ATCs parameterization, a value must be provided to the 
variables of the trace. In some points, neither the user nor the system itself is 
able to provide that value. A clear example is the “Switch” instruction. The 
specification of that instruction says that a task identifier of one of the 
candidates to run shall be returned. In that case the specification should offer 
a value, but in fact it asks for that value and keeps that value in a variable 
from that point. This value is managed from now as a symbolic value and the 
machine must explore all the open possibilities to follow depending on the 
content of that value that can only be supplied by the implementation, 
causing the state explosion problem. 

To avoid this problem, the CTG executes the SUT in parallel with the 
specification expansion process. This process, when a value is needed, is 
driven by the SUT execution, which may provide specific values. It produces 
that all possible continuations of the specification expansion are reduced to 
those that match with the values provided by the SUT in a particular 
execution. 

This approach involves merging three steps: ATCs generation, TProc 
generation and TProcs execution. Hence, no ATC is produced, that is, there 
is no intermediate product, though it may be logged for future uses. 
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With this approach the testing process may be summarized in two steps: 
1) Test Purposes Definitions and 2) Step by step expansion of the 
specification and execution of the lUT. 

3.3.1.1 Test Purposes Definition 

Test purposes (TPs) are defined by a human expert taking into account 
his own experience and environment restrictions. The human tester uses the 
URD and the SRD as entries in test purposes definition. These test purposes 
are written in an informal way. 

As the system goal is to automatically derive ATCs from TPs, the later 
must be formalized. The formalization process implies: 1) to identify 
relevant states into the specifications, 2) to mark relevant states with labels, 
and 3) to rewrite the TPs in terms of action and labels: Definition of Test 
Case Patterns (TCPs). 

A formal TP establishes a logical relationship among several relevant 
states of the LOTOS specification. However, it is not possible to identify 
states in an explicit way inside a LOTOS specification. In LOTOS (as in any 
LTS), the elements on which we work are the transitions. In order to identify 
states, we may give labels (names) to relevant transitions and therefore, 
identify states by means of the transitions that may be performed from them. 

Once the relevant states have been labeled, a TP may be formalized by 
means of a TCP. These TCPs are the representation of a test purpose as a 
chain of labels and/or actions. The setting of the labels to identify objectives 
and subobjectives must be as complete as possible. In this way, the state 
explosion can be avoided as far as the number of branches to examine is 
reduced. 

The TCPs are the result of mapping TPs onto the specification. They 
must be oriented to the requirements captured in the specification. 

A TCP shall contain the following information: the sequence of actions 
and labels that the ATC should include, the maximum number of steps 
between each action/label defined in that sequence, the labels and/or actions 
that the ATC shall avoid, the length of the ATC, the number of ATCs to 
produce, a pool of data for each gate, and an optional initial trace. 

The sequence mentioned above is not a complete trace but just a pattern. 
That is, the user must specify which transitions (states) the ATC should go 
through. Therefore, this sequence is no more than an ordered list of actions 
and gates. The system takes care during the expansion process of traversing 
these transitions. 

Obviously the more specific the sequence is, the easier for the system 
will be to find a test case that fulfils the pattern (or to decide that there is not 
such an ATC). 
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3.3. 1.2 Step by step expansion and execution of the SUT 

This phase includes the following actions: ATC generation, TProcs 
generation from the ATCs, TProc Expected Result Evaluation, and 
Execution of TProcs 

These actions are performed in parallel in a stepwise fashion. At each 
step a new action of the ATC is produced. This action is chosen among all 
the actions that the specification can perform from the current state. If 
needed to, the free variables of this action are assigned a value, producing a 
step of the TProc. This step is composed of an action (an instruction) and 
some parameters. Both the specification and the SUT are fed with the same 
action and the same values in such a way that the expected result is always 
available from the specification. 

When the specification responds with a data, the SUT is also asked for 
this data. The results are compared. If they are different, the TProc is said to 
have failed, otherwise, the process continues until a DEADLOCK is 
produced by the specification or the maximum depth specified in the TCP is 
reached. 

Three kinds of actions may be offered by the specification during this 
process: 

1. Read actions. The specification waits for a value from the 
environment. 

2. Write actions. The specification offers a value to the environment. 

3. Indeterministic actions. The specification waits for a value from the 
SUT. 

When a Read action appears it means that both the specification and the 
SUT are waiting for a value from the environment. In our case, the 
environment would be the CPU that executes an instruction on AT AC with 
some parameters. For that reason, the CTG, which acts as the environment, 
must provide a value to both the specification and the SUT. 

A Write action means that both the specification and the SUT offer a 
value to the environment. This is a checking point. Both returned values are 
compared. If they are equivalent, all the steps until the current one are 
supposed to be successfully executed and the process can go on. 

If not, some step has failed. The VE can not know which step has failed. 
Remember that we are performing conformance testing and not module or 
unit testing. The data offered by the specification represent the expected 
result. 

An Indeterministic action is slightly different to the ones. Both, the 
specification and the SUT must offer a value. But while the SUT knows 
exactly the value that must be offered, the specification merely knows that 
the value it must offer must be in a range or belong to a certain type. The 
only entity involved in the process that knows the value is the 
implementation. In consequence, this value is read from the SUT and offered 
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to the specification. That is, for the specification, it is a Read action and for 
the SUT, it is a Write action. The specification checks the obtained value 
against the corresponding guards. 

With this process no ATCs are produced but directly ETCs, the so-called 
TProcs. No state explosion is produced because the branches are reduced to 
a point where no symbolic values are managed. At every moment we have 
the expected result available. 

If the generated TProcs do not contain points with indeterminism, they 
are totally general and may be applied to any implementation. Regression 
testing may be made just until the point where the TProc failed. 

The TCPs drive the expansion process. That means that when the CTG 
has to choose among several options, the information extracted from the 
TCP is used in order to take a decision. 

3.3. 1.3 Data Values 

At some steps the tool must provide a value both to the specification and 
to the SUT. Two different value sources were used: values provided by the 
user in the TCP and values extracted from the specification. This source is 
used when no values in the TCP are provided. 

In general the chosen value must meet the guards in the option, that is, it 
is not enough with choosing a value but the value must agree with a given 
Boolean expression. For that reason an expression evaluator has been 
introduced within the CTG to facilitate the value assignment. The expression 
evaluator is based on SWl-PROLOG [Jan95] from the University of 
Amsterdam. 

3.4 Test Executor 

The Test Executor (TEX) covers the last phases of the testing process. 

The CTG produces a set of TProcs according to the LOTOS specification 
of the system. These TProcs are a battery of instantiated ATCs for an 
abstract machine. The interface of this abstract machine with the outside 
world is based on the gates defined in the formal specification. The TProcs 
write/read to/from those gates. The values interchanged through the gates are 
those defined in the specification data definition. The TEX deals with those 
values and gates. It interprets the TProcs and commands the SUT. The TEX 
takes into consideration the Tproc expected result provided by the CTG 
assigning a verdict. 
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3.4.1.1 Test Execution 

Once a TProc is obtained, the TEX must perform a set of operations 
aiming to exercise the SUT with the actions and values in the TProc. This 
TProc is expressed as a LOTOS process. 

Summarizing, TProcs are obtained step by step by expansion of the 
specification. One step is produced at each step together with the expected 
result. The expected result may be a constant value offered by the 
specification or a range of values, expressed as a guard over a variable. And 
each step of the TProc together with the expected result is passed to the 
TEX. The TEX exercises the Implementation with the values in the TProc 
and checks that the Implementation is performing according to the TProc (or 
not) by observing the checking points 

3.4.1.2 Verdicts Assignment 

Verdicts are assigned to observations after according to the intention of 
the test (the expected test results). The Tprocs are completed with the 
required Verdict: INCONCLUSIVE, PASS or FAIL. 

The objective to reach within the expansion process is to execute the last 
action in the pattern sequence having met all the checking points. 

It is not possible to check at every action whether the TProc has been 
successfully executed by the lUT. Just at this points where the lUT and the 
specification return values it is possible to compare and assign a verdict. 
These points are the Write and Indeterministic actions. In the Write actions 
both the specification and lUT offer a value. This value may be compared. In 
the Indeterministic actions the lUT offers a value and the specification sets a 
restriction on that value: the value offered by the lUT must fulfil the 
restrictions imposed by the specification. 

3.5 Adaptation Software 

There exists a gap in the CTG between the Formal Specification (written 
in a formal language) and the SUT (real product). There are three aspects to 
be solved: 1) notation translation, 2) specification and SUT coordination (see 
previous section), and 3) communication management between the CTG and 
the SUT. The Adaptation Software (ASW) saves this gap. 

The ASW isolates both the CTG and the TEX from the particular 
interfaces of a lUT, and implements particular features imposed by tbe lUT 
impossible to be covered by the specification. 

In order to be executed the synchronization on specification gates must 
be translated into executable actions over the physical interface of the SUT. 
Depending on the abstraction level of the specification the translation 
process is more o less complicated. 
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The TEX interprets the TProcs and runs in the Host system. The TEX 
sends commands and data to the ASW that is running in the target system. 

The ASW is configured for a twofold objective: 1) mapping the actions 
specified in the LOTOS system specification into actions the SUT 
understands and 2) controlling the communication between the Host and 
Target systems. The ASW receives commands from the TEX, translates 
them into atomic actions over the SUT and executes these actions. This 
architecture intends to isolate the Test Executor from the lUT so that just the 
ASW depends on the lUT. 



4. APPLICATION TO ATAC 



4.1 ATAC Overview 

The Ada Tasking Coprocessor ATAC developed by R-Tech is a memory 
mapped coprocessor dedicated to significantly speed up Ada tasking 
operations, e.g. the rendezvous, and to provide a high degree of accuracy and 
predictability [Roos94a]. The purpose of ATAC is to avoid the drawbacks 
usually associated with the use of run-time Ada tasking, mainly: poor real- 
time response, lack of temporal predictability, and interference between 
interrupt handling and tasking. 

ATAC implements the full Ada83 tasking semantics by hardware, 
running concurrently with the host CPU and unloading it from the whole 
management related to tasks. The coprocessor offers high-level instructions 
for operations that are normally in the run-time system and the tasking 
kernel of an Ada compiler system. These operations are seen from the CPU 
as memory loads and stores. 

The ATAC handles data structures such as entry queues, delay queues, 
ready queues, tasks and hierarchies of tasks, in a private memory and 
incorporates special hardware for managing time and incoming interrupts, 
which replaces system components like the real-time clocks (RTC) and 
interrupt controller [Roos94b]. 

With all these elements, ATAC takes over all scheduling decisions and 
handles interrupts, delays and time of day in a completely integrated fashion 
[Roos94a, Roos94b]: 

• ATAC controls entirely the Preemption, which forces the CPU to 
switch context by setting an interrupt to the host CPU, immediately 
and only when a higher priority task is activated. 

• Incoming interrupts are handled like an intelligent high level Ada 
oriented interrupt controller: interrupts are managed as tasks 
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performing rendezvous sharing in this way in the global system of 
priority management. 

• Exceptions are recognized in the situations that are handled by AT AC. 

• The integrated RTC is used for Ada delay, the added delay until and 
for time of day to support the Ada predefined calendar clock function. 
It can also be advanced from the CPU for debugging purposes. 

The ATAC 2.0 supports a memory mapped hardware interface, and 
operations as seen from the microprocessor are normal memory read and 
write operations. In this sense, it can be said that ATAC 2.0 only acts as a 
slave element on the data bus, and so responding solely to explicit 
transactions. For more information, see [Roos94a]. 

4.2 Requirements Capture and Formalization 

As said before, the starting point for Systems Validation is the 
Requirements Specification. Our concern was to capture in LOTOS the 
required observable external behaviour as the collection of all possible 
sequences of interactions with the environment. 

As a consequence, the specification in LOTOS is Indeterministic in the 
sense that many different implementations may comply with a LOTOS 
specification. Development of LOTOS specifications describing complex 
system is very difficult. The final size was around 12.000 LOTOS lines. 

In one hand, intermediate steps of design are needed in the way from 
"English" to LOTOS. In the other, a systematic architecture should be used 
with LOTOS to avoid inflexible designs difficult to modify and to follow by 
the persons not in charge of the activity. 

The main problems found were the limited resources available in current 
computers and the validation of the LOTOS specification. With respect the 
first problem, the CTG process had to be harmonized with the state of the art 
in processor time. The problem of validating of the specification was 
minimized by using a specific architecture developed within the project. 

4.3 System Under Test (SUT) 

The system under test chosen in this experiment was an ATAC 2.0 based 
CPU (ATAC-CPU). The CPU used was the Instrument Control Processor 
(ICP) of the MIPAS-ICE instrument of ENVISAT-1 and it was adapted to 
embed ATAC 2.0 and associated logic within the current CPU architecture. 
The ATAC-CPU is able to work in three Operation Modes: 

Test Mode : The ATAC-CPU is linked to the Host CPU via a serial RS- 
232 line. The ASW runs on the Breadboard CPU and communicates with the 
Host Computer using the serial link. 
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In this mode of operation, the ASW considers ATAC as a black box, 
which can be stimulated and observed. The functional external interfaces of 
ATAC are the bus interface (instructions to ATAC are bus read or write 
transactions on the bus), the ATAC outcoming ATTN line, the sixteen 
incoming interrupt lines and the RTC clock input. 

Nominal Mode : Used to run a Real-Time Software Application compiled 
with the ATAC option. In this mode, ATAC is present in the CPU memory 
space, the ATAC ATTN line is connected to the CPU and the interrupt lines 
driven from the peripherals in the Breadboard are connected to ATAC in the 
nominal way. ATAC performs full interrupt management. 

Transparent Mode : this mode is foreseen for developing and debugging 
purposes and for non-ATAC run of a Real-Time Software Application in 
Performance Testing. In this mode, ATAC is not present in the CPU 
memory space and neither the ATAC interrupt inputs nor the output ATTN 
line are connected. 

The main components of this ATAC-CPU are: MAS 1750 Microprocessor 
[According to MIL-STD-1750A], AMA31751 Memory Management Unit, 
MCI 031 Standard RBI Chip [OBDH interface]. Real Time Clock, 8 
KWords of Start-up PROM, 256 KWords of RAM, Serial Line Interface, 
PCC (Processor Companion Chip) [ICP Glue Logic], ATAC S/S [ATAC 2.0 
Coprocessor + ATAC Glue Logic]. 

4.4 Tests Generation and Execution on ATAC 

From the formal point of view, ATAC has several passive gates and one 
active gate (ATTN line). ATTN active Gate is the interface that can be 
executed autonomously by the lUT. The rest of interfaces or gates are called 
Passive Gates. To verify that an instruction has been executed correctly, it 
must be checked not only that the passive gates return the proper value but 
also that the active gate is not activated if not explicitly requested. 

The process to generate and execute ATAC tests is as follows: 

1) The CTG generates a test that is translated into ATAC instructions by 
the ASW. 

2) The instructions are sent through a RS-232 serial line to the ATAC- 
CPU. 

3) The ASW (ATAC-CPU) receives these instructions and commands 
them to the ATAC S/S. 

4) Depending on the instruction the ATAC S/S returns or not some 
parameter values. It always returns some ATTN line information (e.g. if it 
has been produced or not). 

5) These parameter values and ATTN information are sent by the ASW 
to RS-232 serial line. 
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6) The ASW transfer these data to the TEX that checks if these values are 
correct or not. 

Only some AT AC instructions must activate the ATTN line. In the other 
instructions it must be checked that it is not produced. When the ATTN line 
has to be activated by an instruction, it must be done within a finite period of 
time (number of RTC pulses). 

To be able to check the occurrence of ATTN in a specific period of time, 
and as explained in the previous paragraph, in Test Mode the ATAC has a 
software programmable clock input, so the time is fully controlled by the 
ASW. In this manner, it can be checked for each ATAC instruction if the 
ATTN line responds as it is expected. 



5. CONCLUSIONS 



5.1 T ools Generated 

The Conformance Test Generator was conceived and developed to 
support the methodology exposed in this paper. It was complemented with a 
Test Executor as well as the needed Adaptation Software to apply the tools 
to the validation of ATAC. These tools have been built on top of existing 
tool to inherit part of the technology within the field of the Formal Language 
and in particular of the LOTOS language. 

5.2 Results Obtained 

The TCP battery used during the ATAC LOTOS specification validation 
was reused in the Conformance Testing activities. If the whole set of test 
covered all the numbered requirements in the URD, they were suitable to test 
the lUT. This fact had an added value: as the logs for stand-alone execution 
were available, results with FAIL verdict could be analyzed. The evolution 
of the model running stand-alone and on-line against the lUT could be 
compared in order to locate possible errors in the specification. The figures 
are: 

Number of TCPs in the battery: 69 
Number of PASS: 34 
Number of FAIL: 25 
Number of INCONCLUSIVE: 8 
Others (execution errors): 2 

Respect to the PASS results, it can be said that the model and the lUT 
evolve in the same way when they are stimulated with the same values by 
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the TCP. The specification was previously validated against the URD 
corresponding to the test, therefore it can be affirmed that the lUT conforms 
to the testing requirement. 

Further analysis is needed to evaluate the FAIL logs. It can be advanced 
that the misunderstanding cases between the specification and the ATAC 
chip are mainly due to bad interpretations of the ATAC documentation or 
errors in the own model conception. This last consideration is related to 
minor bugs during the edition phase of the specification or conceptual errors 
during the ATAC functionality capture. An URD is too abstract to describe a 
system as complex as ATAC and many functional details were recovered 
from the ATAC Compiler Adaptation Guide and even from the Ada code of 
the ATAC simulator. However, this documentation is not suitable enough to 
be sure the model correctness and completeness. 

The evolution of the coverage value growing was registered and it was 
observed that the execution of TCPs with different purpose gave significant 
increments, but a similar TCP gave only a variation in the second or third 
decimal digit. When the number of participant TCPs were growing, the value 
of coverage started to not increase significantly and the value of less than 
70% stabilized for a number of PASS tests next to 40% of the whole battery. 

The interpretation of that 40% of the TCPs covers the 70% of the 
specification can surprise; however, it is a realistic figure: the used metric is 
a measurement if how many internal and external synchronization have been 
exercised. Each test needed a high number of internal actions. A big set of 
functionalities must be previously exercised and therefore there is a lot of 
common synchronization among requirements. For this reason it is supposed 
than an increment of test executions with PASS verdict was not associated to 
an increment of coverage value starting from a determinate number of PASS 
executions. 

5.3 Possible Applications and Future 

The methodology exposed can be applied to any complex system 
implemented in hardware, software or mixed. Candidates are systems with 
complicated behaviours at interface level, with strong relationship between 
their points of observation to the environment. Specially, those systems for 
which high reliability is required. Among others, we think in 
microprocessors, complicated ASICS or similar devices. Embedded Systems 
can be validated using this method at a level of coverage difficult to obtain 
in any other way. 
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Abstract: Recently, the automatic program generation from protocol specification comes 

to be used in order to increase the efficiency of protocol program 
implementation. In the field of OSI, it can be applied successfully to the 
application protocol programs over ROSE. However, the conventional RO 
program generators have problems that they cannot generate complete protocol 
programs. This paper proposes a full-automatic implementation method of 
OSI application protocols over ROSE. Our RO program generator supports 
the program generation for more than one application protocols over ROSE 
such as MHS P2/P7, and enables the presentation context handling. As a 
result, we have succeeded to generate a complete MHS P2 / P7 protocol 
program. This paper describes the detailed design of our RO program 
generator and the results of implementation of P2/P7 program and its 
performance evaluation. The work which we did for the implementation was 
just to specify 370 line P2 / P7 protocol specification. The automatically 
generated P2 / P7 program can provide about 100 operations per second. 
Therefore, the proposed implementation method is considered to achieve as 
high performance as applicable to the practical usage. 
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1. INTRODUCTION 

Recently, the automatic program generation from protocol specification 
comes to be used in order to increase the efficiency of protocol program 
implementation. The stub generator of RPC (remote procedure call) is a 
typical example (Birrel and Nelson, 1984). In the field of OSI, an ASN.l 
(Abstract Syntax Notation One) (ITU Rec. 208 and X.209, 1987) compiler, 
which automatically generates encoder and decoder programs from the 
ASN.l specification of Presentation and Application PDUs (Protocol Data 
Units), is an example of program generation (Hasegawa, Nomura and Kato, 
1992) (Neufeld and Yang, 1990). Since the encoding rule of ASN.l is quite 
complicated, the ASN.l compilers are indispensable in the OSI protocol 
program implementation. However, the program generation by ASN.l 
compilers is limited to encoder and decoder programs because ASN.l 
specifies only the data type of PDUs. Implementers need to write the rest 
parts of programs. 

The program generation can be applied successfully to the OSI 
application protocol programs working over ROSE (Remote Operation 
Service Element) (ITU Rec. X.219 and X.229, 1988), which is considered as 
an extension of RPC in the OSI environment. In the case of those protocols, 
such as MHS (Message Handling System) P2/P7 protocols (ITU Rec.X.413, 
X.4I9 and X.420, 1988) and CMIP (Common Management Information 
Protocol) (ITU Rec. X.710 and X.711, 1988), the protocol behaviors are 
defined in ROSE, and the data types of PDUs and service primitives 
provided for their users are defined in the RO-notation. Therefore, it is 
possible to generate the protocol programs from the specification in RO- 
notation, including the programs for PDU encoding and decoding, and for 
protocol behavior handling, similarly with RPC stub generators. For 
example, the ISODE software (Rose, 1990), which is a public domain OSI 
software widely used for an experimental purpose, uses a Remote Operation 
(RO) program generator called rosy (Remote Operations Stub-generator 
(Y ACC-based)) for protocols over ROSE (Rose, Onions and Robbins, 
1991). 

However, the conventional RO progreim generators have some problems 
that they cannot generate complete protocol programs, in the following 
points. 

(1) In the OSI application layer, there are some cases that more than one 
protocols are used over ROSE. In MHS P2/P7 protocols, P7 protocol, 
which specifies the requests and responses between UA (User Agent) and 
MS (Message Store), transfers interpersonal messages defined by P2 
protocol as user data. In CMIP, data types of managed object information 
transferred by CMIP PDUs are defined in different specification from CMIP 
itself In such cases, the program generation needs to be performed for more 
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than one protocol specifications. But, the conventional RO program 
generators cannot handle these cases. 

(2) In the OSI communications, the data types of PDUs are managed by the 
abstract syntax, and the presentation context containing the object identifier 
value of abstract syntax needs to be defined for an individual presentation 
connection. The conventional RO program generators do not generate 
protocol programs handling the presentation context. 

We have taken account of those problems and implemented our RO 
program generator which can generate protocol programs fully supporting 
application protocols over ROSE. The above problems come from the fact 
that the RO-notation and ASN. 1 specification cannot describe the mapping 
between PDUs specified independently nor assignments of the object 
identifier of abstract syntax. Therefore, we have extended the RO-notation 
and developed a program generator for the specification. Our RO program 
generator is also designed so as to generate protocol programs which have 
more flexible user programming interface than conventional RO program 
generators, and which realize high performance by avoiding data copying. 

This paper describes the detailed design of our RO program generator 
which realizes the full-automatic implementation of OSI application 
protocols over ROSE, and the results that we applied it to the 
implementation of MHS P2/P7 protocol programs. Section 2 briefly 
introduces ROSE protocols and section 3 describes the design principles and 
overview of our RO program generator. Section 4 describes the detailed 
design and section 5 shows the results of implementing MHS P2/P7 protocol 
programs. 



2. BRIEF INTRODUCTION TO ROSE 

ROSE (ITU Rec. X.2I8 and X.2I9, 1988) is an application service 
element of OSI, and uses a protocol stack illustrated in Fig.l. . Among the 
protocols in Fig. 1, an application protocol and ROSE which are shaded are 
targets of automatic implementation. ROSE provides a request-response 
style communication for application protocols such as MHS P2/P7 and 
CMIP, and this request-response is called a remote operation. An entity of 
application protocol (a requester) requests an operation which has some 
arguments using ROSE. Receiving the operation, the peer entity (responder) 
sends back a response which has a result of the operation to the requester 
using ROSE. 

The data types of PDUs of application protocols over ROSE are defined 
using four macros of RO-notation : operation, bind, unbind and error 
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macros. The operation macro is used to specify two kinds of application 
PDUs : an argument and a result of an operation. The bind and unbind 
macros are used to specify application PDUs transferred when an 
application association is established and released, respectively. The error 
macro is used to specify application PDUs which informs a requester of the 
error of operation. Among the application PDUs, those defined by the 
operation and error macros are transferred using ROSE protocol, and those 
defined by the bind and unbind macros are transferred using ACSE. 



Application Protocol (CMIP, MHS) 



ACSE X.227 



ROSE X.229 



OSI Presentation Layer X.216, X.226 

OSI Session Layer X.215, X.225 

OSI Transport Layer X.214, X.224 

OSI Connection Oriented 
Network Service 



Figure 1. Protocol Stack 

The ROSE protocol uses four ROSE PDUs : ROIV (RO-INVOKE), RORS 
(RO-RESULT), ROER (RO-ERROR) and RORJ (RO-REJECT). A ROSE 
PDU transfers not only an application PDU as user data, but also the 
following ROSE protocol control information: operation value which 
specifies a type of operation, and an invoke identifier which is used to map 
the request and response of an operation. 

It should be noted that the service primitives of the application protocols 
over ROSE have the same parameters as their PDUs, and therefore, the data 
types of the service primitives are also defined by RO-notation. 



3. DESIGN PRINCIPLES AND OVERVIEW OF RO 
PROGRAM GENERATOR 



3.1 DESIGN PRINCIPLES 

We have adopted the following principles for our RO program generator. 
(1) As described above, RO-notation is not powerful enough for describing 
a complete application protocol specification. Therefore, our RO program 
generator allows the following specifications to be added into RO-notation. 

• A data type contained in ANY DEFINED BY type and OCTET STRING 
type. This specification defines the mappings between PDUs of more 
than one protocols over ROSE. 
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• The object identifier value for the abstract syntax for the PDU 
definitions. 

• A role of operation, i.e. an operation is requested by the initiator of the 
application association, the acceptor, or both. 

(2) Our RO program generator implements protocol programs supporting 
application protocols and ROSE. The protocol program interfaces between 
user programs for the upper layer side, and ACSE (Application Control 
Service Element) and PL (Presentation Layer) programs for the lower layer 
side. Since the application protocols over ROSE often require the 
invocation of an operation during waiting for a response of another 
operation, the subroutine call based user programming interface which is 
used in RPC stub and ISODE is not sufficient for flexible programming. 
Therefore, the user programming interface of the protocol programs 
automatically implemented adopts the exchange of individual service 
primitives through queues between the user programs and the protocol 
programs. 

(3) As described above, the service primitives and PDLFs of the application 
protocols contain the corresponding parameters, and the user programming 
interface of the automatically implemented protocol programs uses the 
service primitives. In order to avoid data copying, the encoder and decoder 
programs generated by our RO program generator encode PDUs from 
service primitive data and decode PDUs into service primitive buffer 
without using any intermediate working buffers. 

3.2 OVERVIEW 

(1) Our RO program generator consists of the extended ASN.l compiler and 
the protocol behavior routines as shown in Fig. 2. Since individual 
application protocols use the same protocol behavior defined by ROSE, the 
protocol behavior is realized by pre-implemented library routines, i.e. the 
protocol behavior routines. On the contrary, the extended ASN. 1 compiler 
generates the following application protocol specific programs and data 
from a specification in the RO-notation: primitive data types, ASN.l 
encoder / decoder routines, and an operation table containing control data. 

(2) The structure of generated program is shown in Fig. 3. The program 
provides the programming interface based on exchanging service primitives 
through interface queues to user programs. The data types of service 
primitives are generated by the extended ASN.l compiler. The behavior 
routines perform the application protocol behaviors using the encoder / 
decoder routines and the operation table. The encoder / decoder routines 
are used to encode and decode ROSE PDUs and application PDUs. The 
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operation table holds the static information for all operations, a bind and an 
unbind. For each operation, the data includes an operation value, pointers to 
encoder and decoder routines for the PDU and error list. 




Figure 2. Structure of RO Program Generator 





Application Protocol Primitive 

ACSE Primitive with Application PDU 

PL Primitive with Application and 
ROSE PDUs 

Figure 3. Structure of Generated Program 
(3) The protocol behavior routines realize the application protocol 
processing in the following way. 
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• They use a control structure such that they receive a primitive from either 
a user program or a lower layer program (ACSE program or PL 
program), analyze the primitive, make a primitive and sends it to the 
lower layer program or the user program. 

• When encoding a PDU from a service primitive and when decoding a 
PDU into a service primitive, they obtain a pointer to the encoder routine 
and the decoder routine by referring to the operation table. 

They use two kinds of tables in order to manage the dynamic 
information. An association table is prepared for each application 
association. In each association table, a request-response table for mapping 
the request and response is provided. 



4. DETAILED DESIGN 



4.1 INPUT SPECIFICATION TO EXTENDED ASN.l 
COMIPLER 

An example of input specification to the extended ASN.l compiler is 
shown in Fig. 4, which is a part of MHS P2 / P7 protocol specification. In 
this specification, a bind and an operation are defined by RO-notation 
extended as described above. MSBind is a bind, and MessageSubmission is 
an operation. The argument and result of MessageSubmission operation 
have SubmissionArg and SubmissionRes types, respectively, and the 
operation value is 3. These types are defined in ASN.l. For example, 
SubmissionArg type is defined using SEQUENCE type with two elements, 
envelope and content. 

As described in section 3.2, the object identifier of the abstract syntax is 
specified at the line marked with (a) in Fig. 4. The line marked with (b) 
specifies the role of generated program for MessageSubmission operation. 
This operation is invoked by the initiator of an association. The line marked 
with (c) specifies that a P2 PDU whose data type is InformationObject is 
contained inside the content element whose data type is OCTET STRING. 
The line marked with (d) specifies the case that the ANY DEFINED BY type 
contains another data. In this case, the data types contained in the values 
element depends on the value of atype element whose data type is OBJECT 
IDENTIFIER type. The two lines followed by mark (d) specify pairs of the 
data type of contained data and the values of the atype element. 
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P2P7 DEFINITIONS 
BEGIN 

ABSSYN { 2 6 0 1 4 ) -- (a) presentation context 
MSBind ::= BIND -- bind 



ABSSYN { 2 6 0 2 1 } (a) 

MessageSubmission OPERATION 
! ! INITIATOR -- requester -- (b) 

ARGUMENT Submi s s i onAr g 
RESULT Submiss ionRes 

ERRORS { } 

::= 3 -- operation value 

-- P7 PDU 

SubmissionArg ::= SEQUENCE { 
enve lope Enve lope, 

content Content } 

Content ::= OCTET STRING {type = Inf ormationObj ect } --(c) 
Attribute ::= SEQUENCE { 
atype AttributeType, 
values ANY DEFINED atype -- (d) 

( heading SeqOfHeading {26170}, 

body SeqOfBody {26180}, ) 

AttribueType ::= OBJECT IDENTIFIER 
Seqof Heading ::= SEQUENCE OF Heading 
Heading : : = SEQUENCE { ... } 

-- P2 PDU 

InformationObeject ::= CHOICE { 

ipm IPM, } 

-- ROSE PDU 
ROSEApdus : : = 



Figure 4. Example Specification (P2/P7) 

4.2 SERVICE PRIMITIVE TYPE GENERATION 



The extended ASN.l compiler generates two service primitive data types 
in C language from each operation, bind and unbind definitions. One data 
type is for a request primitive and an indication primitive, and the other is 
for a response primitive and a confirm primitive. 

A service primitive data type consists of the following elements: 

• header : common information for all primitives such as a layer identifier, 
an indicator of a request, indication, response or confirm, and an 
association identifier. 

• parameters of lower layer protocols : information needed to encode and 
decode ROSE PDUs and parameters exchanged between lower layers 
and a user program. 

• application PDU 

The data type of an application PDU is specified in ASN. 1 , and the C 
data type corresponding to that is generated by the extended ASN.l 
compiler. As described above, the application PDU field is used both as a 
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working buffer in ASN.l encoding / decoding and as a parameter of a 
primitive. 

/* Mess age Submiss ion Request / Indication Primitive */ 
struct MessageSubmission_req { 

prim_header_t PrimHead; /* header */ 

long Invokeld; /* invoke identifier */ 

Submiss ionArg_t param; /* application PDU : 

argument of operation */ }; 

/* Submiss ionArg Data Type */ 
struct Submiss ionArg { 

Envelope_t envelope; 

Contetnt_t content; }; 
typedef struct Submiss ionArg SubmissionArg_t ; 

/* MessageSubmission Response / Confirm Primitive */ 
struct MessageSubmission_rsp { 

prim_header_t PrimHead; /* header */ 

long Invokeld; /* invoke identifier */ 

long resultFlag; /* Result : Success/Failure */ 

union { 

Submiss ionRes_t acc; /* application PDU : 

Response of operation 

error_t rej ; /* Error Response */; 

} result; }; 

/* Submiss ionRes Data Type */ 
struct Submiss ionRes { 

... } ; 

typedef struct SubmissionRes Submiss ionRes_t ; 

Figure 5. Service Primitive Data Types of Operation 

Figure 5 shows the request and response primitive data types generated 
from an MessageSubmission operation specified in Fig. 4. The primitive 
data types are defined using C data type struct which holds the above 
mentioned information. For example, as for the request / indication 
primitive, invokelD element is an invoke identifier of ROSE PDU, and is 
used for encoding and decoding a ROSE PDU. Param element is a 
parameter of application PDU, i.e., an argument of operation, and the data 
type is specific to each operation. The response and confirm primitives 
include the following elements as well as invokelD element. ResultFlag 
element is a flag indicating whether the operation has been successfully 
performed by the responder or not. Result element is realized by C union 
structure and is either a result application PDU which is specific to each 
operation or an error application PDU. Acc element is the result application 
PDU, and rej element is the error application PDU. 

It should be noted that the data types have the structure allocated in a 
contiguous memory area without using pointers as long as possible. The 
SEQUENCE and SET types which have nested structures do not use pointers 
to child components, but contain the values of child components themselves. 
In Fig. 5, C struct SubmissioArg corresponds to SubmissionArg of 
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SEQUENCE types, and have C struct themselves such as Envelopej and 
Contentjt. 

The SEQUENCE OF and SET OF types which include ordered and 
unordered component values, respectively, have C data types which consist 
of an integer indicating a component value number, and a pointer to 
component values themselves. Figure 6 shows the C data types 
corresponding to SeqOfHeading type in Fig. 4. Cnt element and data 
element are the number of heading values and the pointer to the array of 
heading values. The memory eirea for storing heading values is allocated as 
a contiguous array, not as a list with individual heading values linked by 
pointers 

struct Q_SeqOfHeading { 

u_long cnt; /* Number of Component Values */ 

Heading_t *data; /* Pointer to Array of Heading Values */ }; 

Figure 6. C Data Types of SEQUENCE OF Type 

4.3 ENCODER / DECODER GENERATION 

The extended ASN.l compiler generates a C data type and encoder / 
decoder routines for a data type which is newly defined using structured 
types of ASN.l such as SEQUENCE and SET. On the contrary, those for 
primitive types such as INTEGER and OCTET STRING types are pre- 
implemented as a library. 

In order to deal with PDUs containing upper layer PDUs as user data, the 
mapping function is added to ANY DEFINED BY type and OCTET STRING 
type in the following way. 

(1) A data type of upper layer PDU is defined using DEFINED BY phrase as 
shown in (d) of Fig. 4. The actual data type is dynamically chosen among 
the candidate data types, i.e, SeqOfHeading and SeqOfBody of Fig. 4. The 
data types are determined dynamically by an object identifier value at atype 
element. For example, when the object identifier value of type is {2 6 1 7 
0}, the data type of values is SeqOfHeading. 

(2) The data type of ANY with DEFINED BY phrase is a C data structure 
union which consists of all data types defined by DEFINED BY phrase, and 
it is generated by the extended ASN.l compiler. Figure 7 shows the C data 
type generated from Attribute type which includes ANY DEFINED BY type. 
Atype element contains an object identifier value indicating data type of 
values element. Values element is a union of the C data types corresponding 
to the above candidate date types. 
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/* C data type for Attribute */ 
struct 0 Attribute 

{ AttributeType_t atype; /* Object Identifier */ 

union /* Union of Candidate Types */ 

{ SeqOfHeading_t heading; /* Candidate Type 1 */ 

SeqOfBody_t body; /* Candidate Type 2 */ 

} values; }; 

Figure 7. C Data Type for Attribute 

(3) When encoding the parameter of ANY, an encoder routine first checks 
an object identifier value of atype element of working buffer, and then calls 
the encode routine corresponding to the object identifier value. On the 
contrary, when decoding, a decoder routine first decodes the atype element 
of PDU, and then calls the decoder routine corresponding to the decoded 
object identifier value. 

void decodeAttribute (var , edata, index, 
error, ida) 

char *var; STRING *edata; 

u_long * index; ERROR * error; 

ID ^ida; 

{ Attribute *q_var; 
long cnt = 0 ; 

u_long next_ob j = 0 ; 

/* decoding identifier and length octets */ 

cnt = skp_idlenN (edata, index, &next_obj , ida, error); 

next_obj += * index; 



q_var = (Attribute *) var; 
decoding type */ 

decodeobjectN (& ( *q_var) . type, edata, index, 
error, id_infoN + 31, (u_long) 0); } 

if ( ( *error ) . errlevel < 2) { 

if (obj_chk ( Sc ( * q_var ) . type , Scheadingid) == TRUE) { 
decodeSeqOfHeading ( 

Sc ( * q_var ) . value . heading , 
edata, index, error, id_info + 44) ; } 
else if (obj_chk (Sc { *q_var ) . type, Scbodyld) == TRUE) { 
decodeSeqOfBody (Sc (*q_var) .value. body, 
edata, index, error, id_info + 45); } 

else { 

ERRSETN( error, FATALN, 10, ida, * index ) ; } 



} 

/* Object Identifier Values : Constants */ 

OBJID headingid { { 2, 6, 1, 7, 0}, 5}; 

OBJID bodyld { { 2, 6, 1, 8, 0}, 5}; 

Figure 8. Decoder Routine of Attribute Type 

Figure 8 shows a part of decoder routine of Attribute type in Fig.4 which 
includes the above ANY DEFINED BY type. Octets to be decoded are stored 

in edata variable, and the decode result is set in var variable. First, the 
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decoder routine decodes identifier and length in the octets to be decoded 
using skipJdlenN library routine. Secondly, the decoder routine decodes 
object identifier of atype using decodeobjectN library routine. The decoded 
object identifier value is set in atype element of var variable. Thirdly, the 
routine compares the decoded object identifier value and candidate values 
using objjchk library routine. The variables which hold candidate object 
identifier values are generated from an ANY DEFINED BY phrase by the 
extended ASN. 1 compiler. Headingld and bodyld variables in Fig. 8 are the 
examples, and they are used as arguments to obj_chk routine. Eventually, 
the decoder routine finds the decoder routine corresponding to the object 
identifier value, and calls the decoder routine, i.e., either 
decodeSeqOfHeading routine or decodeSeqOfBody routine which are 
generated by the extended ASN. 1 compiler. 



5. MHS P2/P7 IMPLEMENTATION AND COMMUNICATION 

EXPERIMENT 



5.1 MHS P2/P7 PROTOCOL PROGRAM GENERATION 

MHS P2/P7 protocol, which is defined over ROSE, is used to transfer an 
IPM (Interpersonal Message) between UAs (User Agents) and MSs 
(Message Stores). P2 protocol defines the format of IPM. P7 protocol 
defines the protocol between UAs and MSs, such as the submission of a 
message to an MS and fetch of a message stored in an MS. 

We have developed the P2 /P7 program using the proposed 
implementation method. We have written a P2 / P7 specification in the 
extended RO- notation and generated the program using the extended ASN.l 
compiler. The specification supports three operations : list, fetch and 
deletion of a message, and its size is 370 lines. From the specification, 
about 1 1 K line C progreuns are generated. The details are shown in Table 
1. Since protocol behavior routines are about 2.4 K lines, the total P2 / P7 
program size is about 13.4 K lines. 

Among the 370 lines of the P2 / P7 specification, the 350 lines have been 
just copied from the specification in the ITU Recommendations (ITU Rec. 
X.413, X.419 and X.420), and just the 20 lines which specify the mapping 
of PDUs, presentation context identifiers and so on have been additionally 
written. It has taken just two days to write the specification and to generate 
the programs from the specification. 
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Table I. Sizes of Specification and Generated Program 



specification 


lines 


program 


lines 


RO-notation 


80 


operation table 


120 






primitive data types 


240 


ASN.l 


290 


encoder / decoder 


10,640 



5.2 COMMUNICATION EXPERIMENT 



In order to run the P2 / P7 program, UA and MS programs for testing 
have been developed. The P2 / P7 program, UA or MS program are built 
into the previously developed OSI program which supports from ACSE to 
LLC protocols. The total OSI program, whose structure is shown in Figure 
9, is run as a single process on UNIX operating system. The execution of 
the above programs is controlled by a pseudo-kernel program which 
provides the scheduling function and inter-program communication 
function. For evaluating the generated program, we performed the 
following experiments. 




Figure 9. Program Structure 

(1) Communication with Other MHS P2 / P7 Program 

In order to validate the correctness of the automatically generated P2 / 
P7 program, we have performed the communication experiment between the 
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generated P2 / P7 program with MS program and a UA program which we 
previously manually developed. The MS program is run on a Sun SS-20 
workstation and the UA program is run on a personal computer. These are 
connected via a serial line. The message submit, list and fetch operations 
are executed between the both programs, and the generated P2/P7 program 
with the MS program provides the correct MS behavior. 

(2) Overall Performance Measurement 

In order to measure the performance, the communication experiments are 
performed between the generated P2 / P7 program with UA program and the 
P2 /P7 program with MS program. The network configuration is shown in 
Fig. 10. The two Sun SS-20 workstations (SuparSPARC II 60 MHz) which 
aie connected via Ethernet LAN are used. 
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^ 




UA Program 
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Figure 10. Network Configuration 

We have measured the response times of list and fetch operations under 
the following conditions. 

• list operation : The MS program searches the mail box, and returns a 
response which contains an originator name, a recipient name, a subject 
and a message identifier. 

• fetch operation : The MS program reads a message whose body size is 1 
K bytes, and returns a response which contains the message as a body. 
The response times are measured by running 10,000 operations 

consecutively, and the measurement is performed ten times for each 
operation. A response time is a duration between the time when the UA 
program sends a request of operation and the time when it receives the 
response. The average response times of list and fetch operations are about 
8.8 ms and 10.8 ms, respectively. As for a fetch operation, the processing 
tines of P2 / P7 programs of UA and MS sides are about 0.59 ms and 0.56 
ms, respectively. As shown in the results, the automatically generated P2 / 
P7 program can support about 100 operations per second. 

(3) Detailed Performance Measurement 

We have evaluated the performance improvement caused by the 
proposed implementation method. The duration from the time of receiving a 
fetch request primitive from the MS program to the time of sending a P- 
DATA request primitive to the PL program is measured for both the 
proposed implementation method and the traditional method. 
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As for the proposed method, the duration is measured during the 
performance measurement of (2), and it is about 0.29 ms. On the contrary, 
as for the traditional method, we have developed a testing program for 
estimating the duration. The testing program uses a traditional method and a 
traditional ASN.l compiler (Hasegawa, Nomura and Kato, 1992). The 
working buffer for an application PDU of fetch argument is not a parameter 
of a fetch request primitive. Therefore, the testing program converts the 
parameter of the fetch request primitive to the working buffer before it 
encodes using the ASN. 1 encoder routine generated by the ASN. 1 compiler. 
The duration is measured running the testing program on the same sun SS- 
20 workstation, and it is about 0.38 ms. The result shows that proposed 
direct encoding improves the P2/P7 program performance at about 30 %. 



6. CONCLUSION 

This paper has proposed a full-automatic implementation method of OSI 
application protocols over ROSE. We have realized a RO program 
generator consisting of the extended ASN.l compiler and the protocol 
behavior routines. They support the program generation for more than one 
application protocols over ROSE such as MHS P2/P7, and enables the 
handling the presentation context. We have implemented MHS P2 / P7 
protocol using our RO program generator. The results of implementation 
and communication experiment have made clear the following. 

• The proposed method has achieved the full-automatic P2 / P7 protocol 
implementation. It took a few days to implement it since the required 
work was just to specify 370 line P2 /P7 protocol specification. Besides, 
since we did not need write any programming code at all, we did not 
encounter any program bug during the implementation. 

• The automatically generated P2 / P7 program can provide about 100 
operations per second. Besides, the processing time of P2 / P7 process is 
less than 1 ms. Therefore, the proposed implementation method is 
considered to achieve as high performance as applicable to the practical 
usage. 
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WHY REWRITING LOGIC 

I will introduce the main ideas of rewriting logic [11] — a logic for the specifica- 
tion, prototyping and programming of concurrent systems in which concurrent 
computation exactly corresponds to logical deduction — and will discuss some 
promising directions for its use as a logical and semantic framework for dis- 
tributed computing and communication protocols. An important aspect is its 
wide- spectrum character. Thus, on the one hand it connects smoothly with — 
and provides a formal foundation for — notations suitable for the early phases of 
software design, such as architectural description languages and object-oriented 
modeling languages [14, 19]; and on the other hand it also provides a natural 
implementation path through subsets of the logic that are efficiently imple- 
mentable as distributed or mobile languages [9]. Similarly, rewriting logic spec- 
ifications, when supported by appropriate tools, can be used in a wide range of 
specification, prototyping, code generation, testing, formal analysis, and formal 
verification efforts to reach high levels of assurance about a system’s correct- 
ness. All these capabilities seem potentially useful for specifying, prototyping, 
testing, validating, and implementing distributed systems in general and com- 
munication protocols in particular; and they offer the promise of substantially 
narrowing the gap between specification and code, and of reaching high assur- 
ance about the correctness of implementations that can themselves be realized 
in efficient subsets of rewriting logic. 
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For such applications, an attractive feature of rewriting logic is its simple 
and smooth integration of three levels of description that ultimately need to be 
addressed in a distributed system’s formal specification, namely, the data level 
of data structures and functions, the dynamic level of processes and concurrent 
computation, and the requirements level of formal properties that must be 
satisfied by the system. 

Indeed, a rewrite theory is a triple TZ = (S, E, i?), with (S, E) an equational 
theory, and R a collection of labeled rewrite rules that are applied modulo the 
equations E; they axiomatize the basic concurrent transitions of the specified 
system. The two main kinds of axioms in a rewrite theory, namely, equations 
t = t' , and rewrite rules r : t — > t' ^ specify, respectively, the data and dynamic 
levels. That is, the data types and the overall state space of the system are 
axiomatized as the initial algebra Ty,^e associated to the equational specification 
(S,E), and the rewrite rules^ in R are understood as local rules of concurrent 
change in the intended system, so that rewriting logic deduction with such 
rules describes exactly those concurrent computations possible in the system. 
This one-to-one correspondence between concurrent computation and logical 
deduction is of course of great practical usefulness, because it means that, given 
an adequate implementation of rewriting logic, a rewrite theory TZ becomes 
an executable specification of the concurrent system that it formalizes. Such 
a specification can then be used for rapid prototyping, symbolic simulation, 
formal analysis, and formal verification, to uncover design errors very early in 
the design process; and can also be used to generate correct code by means of 
adequate semantics-preserving transformations. 

Since a rewrite theory TZ has an initial model Tn [H] that mathematically 
characterizes the system as a category whose objects are the system’s states 
and whose morphisms are the system’s concurrent computations, formal sys- 
tem properties are in essence inductive properties of such a model. They can 
be expressed either in a natural extension of rewriting logic allowing arbitrary 
quantification, or in a temporal or modal logic providing a convenient nota- 
tion for such properties. In this way, the three levels of data, dynamics and 
properties are naturally and seamlessly addressed. 

A REFLECTIVE LOGICAL AND SEMANTIC FRAMEWORK 

Being a semantic framework means that rewriting logic, instead of building in 
a particular model of concurrency or distribution such as, for example, process 
algebras, allows a wide range of such models — including indeed process algebras 
and languages such as LOTOS, but including also many other models such as 
Petri nets. Actors, the Unity language, datafiow, concurrent objects, concur- 
rent graph rewriting, the 7r-calculus, and real-time systems [12, 13]. Being a 
logical framework means that rewriting logic can be used as a metalogic in which 
many other logics can be naturally defined and executed [10]. Natural and sim- 
ple faithful such representations have been defined for a wide range of logics 
including classical, intuitionistic and linear logic, temporal and modal logics, 
inductive equational logic, and any logics with a sequent calculus presentation. 
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In particular, logical representations of this kind have been used to define and 
build theorem proving tools in a rewriting logic language such as Maude [3]. 
The way in which a model of computation, a programming language, a de- 
sign or architectural language, or a logic are represented in the rewriting logic 
framework is by means of representation maps of the form 

$ : C — > RWLogic. 

Such maps give a rewriting logic semantics to the language C in question. 

A key property of rewriting logic is that it is reflective [6, 2], in the sense 
that rewriting logic can represent its own metalevel as well as those of other 
logics. In fact, there is a finitely presented rewrite theory U that is universal in 
the sense that for any finitely presented rewrite theory TZ (including U itself) 
we have the following equivalence 

TZ \~ t — y t^ lA h (7^, t) — iJZ^ V) ^ 

where TZ and t are terms representing TZ and t as data elements of U. Specif- 
ically, 7?. is a term of sort Module, and ? is a term of sort Term in U. Since U 
is representable in itself as a term of sort Module, we can achieve a “refiective 
tower” with an arbitrary number of levels of refiection, since we have 

TZ\-t-^t' ^ U\- (flZ~t) ^ (^,F) ^ UV- (W, !^~t)) ^ (W, . . . 

For efficiency reasons, the Maude language provides key features of the universal 
theory W in a built-in module called META-LEVEL that supports an arbitrary 
number of levels of reflection [4]. 

An important use of refiection is defining and executing within rewriting 
logic itself representation maps ^ : C — > RWLogic. Such maps associate to 
each module M in the language C a rewrite theory $(M) in RWLogic. In se- 
mantic framework applications the language C can be a model of computation, 
a programming language, or an architectural description language; in logical 
framework applications £ is typically a logic. In all cases, both C and $ are 
metalevel entities that are, in principle, outside rewriting logic; however, thanks 
to refiection, they can be internalized — or as it is sometimes said reified — within 
rewriting logic. The idea is that in the universal theory U rewrite theories are 
already reified in an algebraic data type Module; we can then define another 
such data type Module/: reifying the modules in £, and can reify $ as a function 

$ : Module£ — > Module. 

Since typically $ is a total computable function, by general results of Bergstra 
and Tucker [1] it can always be specified by Church-Rosser and terminating 
rewrite rules, and therefore can be defined and executed in a refiective rewriting 
logic language such as Maude. 

Yet another important application of refiection is that rewriting logic com- 
putations can be controlled at the metalevel by means of internal strategies 
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defined with rewrite rules [6, 2]. This is of great practical use for the formal 
analysis of highly concurrent systems such a communication protocols, because, 
once they have been specified in rewriting logic, we can define strategies that 
explore all the possible concurrent computations from some given initial state 
or states, and that check whether some key property is satisfied or violated in 
the new states. In this way, formal specifications can be analyzed and corrected 
very early in the design process by what amounts to symbolic model checking 
and symbolic testing. 

RECENT AND FUTURE DEVELOPMENTS 

Rewriting logic is at present a young international research program with over 
a hundred papers by authors in Europe, the US and Japan, and three language 
implementations (see the survey [13] and the upcoming Second Workshop Pro- 
ceedings [8]). We are still in an early phase in the task of applying rewriting 
logic to distributed computing and communication protocols. However, in ad- 
dition to the work on foundations, on models of concurrent computation, and 
on languages, some recent research focusing specifically on this area seems quite 
promising. For example, the paper [7] shows how cryptographic communica- 
tion protocols and attackers can be specified, executed, tested, and analyzed 
in Maude, and how adequate execution strategies can search and find security 
violations. Similarly, Appendix B of [4] discusses a reliable broadcast proto- 
col Maude specification currently being jointly developed by researchers at the 
University of California, Santa Cruz, Stanford University, and SRI Interna- 
tional (Denker, Garcia-Luna, Meseguer, Smith, Olveczky, and Talcott); using 
executable specifications very early in the design process has quickly exposed a 
number of mistakes and deadlocks in the initial design. In the same vein, sev- 
eral fault-tolerant communication protocols have also been specified in Maude, 
and active network algorithms written in the PLAN language are currently be- 
ing specified and formally analyzed in Maude as part of a joint collaboration 
between researchers at the University of Pennsylvania and at SRI International 
(Gunter, Meseguer, and Wang). Other very promising developments include 
the work of Najm and Stefani using rewriting logic to specify computational 
models for open distributed systems [15], Talcott’s work on open distributed 
components [18], Pita’s and Marti-Oliet’s work specifying a network manage- 
ment system in rewriting logic [17], Nakajima’s work on the semantics of the 
calculus of mobile ambients and on specifying a Java/ORB implementation 
of a network management system [16], and Wirsing’s and Knapp’s work on a 
systematic translation from object-oriented design notations to Maude specifi- 
cations [19]. 

Much more work remains ahead. More experience should be gained through 
examples and case studies; compositional aspects — so that protocols and other 
distributed systems and services can be specified, reasoned about, and built in 
a much more modular way — should be systematically studied; specification and 
proof techniques for system properties at the requirements level — in adequate 
temporal or modal logics above rewriting logic — also need to be much further 
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advanced; and efficient implementations of distributed and mobile rewriting 
logic languages need to be developed. All this will require a lively international 
cooperation between individual researchers and entire research teams that is 
already taking place and whose prospects seem very encouraging. 
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Notes 

1. Both equations and rewrite rules can be conditional, but for simplicity I discuss the 
unconditional case. 
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Abstract: 

Test generation and execution are often hampered by the large state spaces of the systems 
involved. In automata (or transition system) based test algorithms, taking advantage of 
symmetry in the behavior of specification and implementation may substantially reduce 
the amount of tests. We present a framework for describing and exploiting symmetries in 
black box test derivation methods based on finite state machines (FSMs). An algorithm 
is presented that, for a given symmetry relation on the traces of as FSM, computes a 
subautomaton that characterizes the FSM up to symmetry. This machinery is applied to 
Chow’s classical W-method for test derivation. Finally, we focus on symmetries defined 
in terms of repeating patterns. 
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1 INTRODUCTION 

It has long been recognized that for the proper functioning of components in open and 
distributed systems, these components have to be thoroughly tested for interoperability 
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and conformance to internationally agreed standards. For thorough and efficient testing, 
a high degree of automation of the test process is crucial. Unfortunately, methods for 
automated test generation and execution are still seriously hampered by the often very 
large state spaces of the implementations under test. One of the ways to deal with this 
problem is to exploit structural properties of the implementation under test that can be 
safely assumed to hold. In this paper we focus on taking advantage of symmetry that is 
present in the structure of systems. The symmetry, as it is defined here, may be found 
in any type of parameterized system: such parameters may for example range over IDs 
of components, ports, or the contents of messages. 

We will work in the setting of test theory based on finite state machines (FSMs). 
Thus, we assume that the specification of an implementation under test is given as an 
FSM and the implementation itself is given as a black box. From the explicitly given 
specification automaton a collection of tests is derived that can be applied to the black 
box. Exploiting symmetry will allow us to restrict the test process to subautomata 
of specification and implementation that characterize these systems up to symmetry 
and will often be much smaller. The symmetry is defined in terms of an equivalence 
relation over the trace sets of specification and implementation. Some requirements are 
imposed to ensure that such a symmetry indeed allows to find the desired subautomata. 
We instantiate this general framework by focusing on symmetries defined in terms of 
repeating patterns. Some experiments with pattern-based symmetries, supported by a 
prototype tool implemented using the OPEN/CiESAR tool set [14], have shown that 
substantial savings may be obtained in the number of tests. 

Since we assume that the black box system has some symmetrical structure (cf. 
the uniformity hypothesis in [15, 6]), it is perhaps more appropriate to speak of gray 
box testing. For the specification FSM it will generally be possible to verify that a 
particular relation is a symmetry on the system, but for the black box implementation 
one has to assume that this is the case. The reliability of this assumption is the tester’s 
responsibility. In this respect, one may think of exploiting symmetry as a structured 
way of test case selection [13, 4] for systems too large to be tested exhaustively, where 
at least some subautomata are tested thoroughly. 

This paper is not the first to deal with symmetry in protocol testing. In [20], similar 
techniques have been developed for a test generation methodology based on labeled 
transition systems, success trees and canonical testers [3, 24]. Like in our case, sym- 
metry is an equivalence relation between traces, and representatives of the equivalence 
classes are used for test generation. Since our approach and the approach in [20] start 
from different testing methodologies, it is not easy to compare them. In [20], the sym- 
metry relation is defined through bijective renamings of action labels; our pattern-based 
definition generalizes this approach. On the other hand, since in our case a symmetry 
relation has to result in subautomata of specification and implementation that char- 
acterize these systems up to the symmetry, we have to impose certain requirements, 
which are absent in [20]. 

In [18], symmetrical structures in the product automaton of interoperating systems 
are studied. It is assumed that the systems have already been tested in isolation and 
attention is focused on pruning the product automaton by exploiting symmetry arising 
from the presence of identical peers. In the present paper, we abstract away from 
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the internal composition of the system and focus on defining a general framework for 
describing and using symmetries on FSMs. 

This paper is organized as follows. Section 2 contains some basic definitions concerning 
FSMs and their behavior. In Section 3, we introduce and define a general notion of trace 
based symmetry. We show how, given such a symmetry on the behavior of a system, 
a subautomaton of the system can be computed, a so-called kernel, that characterizes 
the behavior of the system up to symmetry. In Section 4 we apply the machinery to 
Chow’s classical W-method for test derivation. In Section 5 we will instantiate the 
general framework by focusing on symmetries defined in terms of repeating patterns. 
Section 6 contains an extensive example, inspired by [23]. Finally, we discuss future 
work in Section 7. Due to space limitations, proofs have been left out. 

2 FINITE STATE MACHINES 

In this section, we will briefly present some terminology concerning finite state ma- 
chines and their behavior, that we will need in the rest of this paper. 

We let N denote the set of natural numbers. (Finite) Sequences are denoted by greek 
letters. Concatenation of sequences is denoted by juxtaposition; € denotes the empty 
sequence and the sequence containing a single element a is simply denoted a. If a 
is non-empty then first(a) returns the first element of cr and last{a) returns the last 
element of a. 

If V and W are sets of sequences and a is a sequence, then a W = {a r \ r e W] 
and V W = U^gv ^ ^ ^ symbols, we define = {g} and, for i > 0, 

X* = X*-i U X X^-^ As usual, X* = U,-^n 

Definition 2.1. A finite state machine (FSM) is a structure A = (5, H, E, where 

■ 5 is a finite set of states 

■ E a finite set of actions 

■ EQSxUxS is Si finite set of edges 

■ s^ e S is the initial state 

We require that A is deterministic, i.e., for every pair of edges (s, a, s'), (s, a, s") in 
Ea, s' = 

We write 5^, E^, etc., for the components of an FSM A, but often omit subscripts 
when they are clear from the context. We let s, s' range over states, a,a' ,b,c, . . . over 
actions, and e, e' over edges. If e = (s, a, s') then act(e) = a. We write s s' 
if {s,a,s') e E and with s we denote that s s' for some state s'. A 
subautomaton of an FSM A is an FSM B such that s^ = 5^, Sjs c 5^, E^ c 
and Eb Q E A’ 

An execution fragment of an FSM A is an alternating sequence y = soa\s\ • -anSn of 
states and actions of A, beginning and ending with a state, such that for all / , 0 < / < n, 

we have Si — Si^\ . If = Sn then y is a loop, if n ^0 then y is a non-empty loop. 
An execution of A is an execution fragment that begins with the initial state of A. 
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For y = soa\s\ • - an Sn an execution fragment of A, trace(y) is defined as the 
sequence a\ a 2 ••• an. If cr is a, sequence of actions, then we write s s' if A has an 
execution fragment y with firstly) = s, last(y) = s', and trace(y) = a. If y is a loop, 
then (7 is a looping trace. We write s if there exists an s' such that s s', and 
write traces(s) for the set [a e | s We write traces(A) for traces(s^). 

□ 

3 SYMMETRY 

In this section we introduce the notion of symmetry employed in this paper. 

We want to be able to restrict the test process to subautomata of specification and 
implementation that characterize these systems up to symmetry. In papers on exploiting 
symmetry in model checking [2, 8, 10, 11, 12, 17], such subautomata are constructed 
for explicitly given FSMs by identifying and collapsing symmetrical states. We are 
concerned with black box testing, and, by definition, it is impossible to refer directly 
to the states of a black box. In traditional FSM based test theory, FSMs are assumed 
to be deterministic and hence a state of a black box is identified as the unique state of 
the black box that is reached after a certain trace of the system. Thus it seems natural 
to define symmetry as a relation over traces. 

Our basic notion of symmetry on an FSM A, then, is an equivalence relation on 
(E^)*, such that A is closed under the symmetry, i.e., if a sequence of actions is 
symmetrical to a trace of A then the sequence is a trace of A too. 

The idea is to construct from the specification automaton an automaton such that its 
trace set is included in the trace set of the specification and contains a representative trace 
for each equivalence class of the symmetry relation on the traces of the specification. 
In order to be able to do this, we need to impose some requirements on the symmetry. 
For the specification we demand (1) that each equivalence class of the symmetry is 
represented by a unique trace, (2) that prefixes of a trace are represented by prefixes 
of the representing trace, and (3) that representative traces respect loops. The third 
requirement means that if a representative trace is a looping trace, then the trace with 
the looping part removed is also a representative trace. This requirement introduces 
some state-based information in the definition of symmetry. 

These requirements enable us to construct a subautomaton of the specification, a 
so-called kernel, such that every trace of the specification is represented by a trace from 
the kernel. Of course, it will often be the case that the symmetry itself is preserved 
under prefixes and respects loops, so the requirements will come almost for free. 

For the black box implementation, we will, w.r.t. symmetry, only demand that it is 
closed under symmetry. So if tests have established that the implementation displays 
certain behavior, then by assumption it will also display the symmetrical behavior. In 
Section 4, where the theory is applied to Mealy machines, we will in addition need 
a way to identify a subautomaton of the implementation that is being covered by the 
tests derived from the kernel of the specification. 

Definition 3.1. A symmetry S on an FSM A is pair (~, O'") where ~ is a binary 
equivalence relation on (E^)*, and O'" : (E^)* (5^^)* is a representative function 

for ~ such that: 
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1. ^ is closed under If cr € traces (A) and a ~ r, then r e traces (A). 

2. Only traces of the same length are related: If or ~ r, then |or| = |t|. 

3. O'” satisfies: 

(a) o'" ~ or 

(b) r ~ or r'' = or'’ 

(c) O'* is prefix closed onA.lfcr a e traces{A) and {a af = r b, then cr^ = r 

(d) O'" is loop respecting on representative traces: If (a\ 02 = a\ 02 02 , e 

traces{A) and ot 2 is a looping trace, then (ori o^Y ^oxa^. 

The class of traces r such that r ~ or is denoted with [a]s, or, if S is clear from the 
context, [or]. □ 

As mentioned above, we will demand that there exists a symmetry on the specification, 
while the implementation under test is required only to be closed under the symmetry. 
Note that (cr^Y = 

Definition 3.2. Let S = (~, O'”) be a symmetry on FSM A. A kernel of A w.r.t. S is 
a subautomaton 1C of A, such that for every a e traces (A), cr^ e traces{K). □ 

In the remainder of this section, we fix an FSM A and a symmetry S = 00 on 

A. Figure 1 presents an algorithm that constructs a kernel of A w.r.t. 5. The algorithm 
basically explores the state space of A, while keeping in mind the trace that leads to 
the currently visited state. As soon as such a trace contains a loop, the algorithm will 
not explore it any further. 

In Figure 1, enabled(s, A) denotes the set of actions a such that contains an 
edge (s, a, s'), and for such an a, eff(s, a, A) denotes s'. Furthermore, repr(p, E) 
denotes the set F of actions such that a g F iff there exists an action b e E such that 
a = {a bY ■ We will only call this function for a such that = a. By definition 
of ()'■, for some action c, {a bY = c = a c. So, since A is deterministic and closed 
under 21 , F ^ E and if E is non-empty, F is non-empty. This justifies the function 
choose(F) which nondeterministically chooses an element from F. 

Theorem 3.3. Let K = Kernel(>I,5). If cr g traces{A), then a'’ g traces{K). 

4 TEST DERIVATION FROM SYMMETRIC MEALY MACHINES 

In this section we will apply the machinery developed in the previous sections to 
Mealy machines. There exists a wealth of test generation algorithms based on the 
Mealy machine model [1, 5, 7]. We will show how Chow’s classical W-method [7] can 
be adapted to a setting with symmetry. The main idea is that test derivation is not based 
on the entire specification automaton, but only on a kernel of it. A technical detail here 
is that we do not require Mealy machines to be minimal (as already observed by [19] 
for the setting without symmetry). 

Definition 4.1. A Mealy machine is a (deterministic) FSM A such that 



= W/O) I / G A O G 0^1 




function Kemel(^, S): FSM; 
var /C; 

procedure Bu0dJt(5, a. Seen); 
var a, b, s, s', E, F; 

begin 



if j ^ Seen 

then E := enabled{s. A); 

F :=0; 

while £ ^ 0 

do a := choose{repr(a, £)); 
s' ;= ^(s,a,A); 

Sk ■= Sk U {j'}; 

Sk; := U [a]; 

Ek :=£AcU{(j,fl,/)}; 
BuildJt(;', a a. Seen U {j}); 
F :=FU{a}; 

£ := £ \ [a]; 

for each fe€£.aa~crfc 
do £ := £ \ [b]; 

od; 

od; 



end; 



fi; 



begin 

^0 „o . 

Sk := 

Sk := 0; 

E)c ■= 0 ; 
BulldJt(j^, e, 0); 
return /C; 

end. 



Figure 1 The algorithm Kernel 
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where and Oj^ are two finite and disjoint sets of inputs and outputs, respectively. 
We require that A is input enabled and input deterministic, i.e., for every state s e 

and input i e there exists precisely one output o € such that 5 

Input sequences of A are elements of (/^)*. For ^ an input sequence of A and 

s, 5 ' € 5 ^, we write s s' if there exists a trace o such that s ^ 

is the result of projecting o onto /^. In this case we write outcome , s) = a; the 
execution fragment y with first(y) = s and trace(y) = a is denoted by exec^is, |). 
A distinguishing sequence for two states s, s' of A is an input sequence ^ such that 
outcome , s) # outcome s'). We say that ^ distinguishes s from s' . □ 

In Chow’s paper, conformance is defined as the existence of an isomorphism between 
specification and implementation. Since we do not assume automata to be minimal, we 
will show the existence of a bisimulation between specification and implementation. 
Bisimilarity is a well-known process equivalence from concurrency theory [ 21 ]. For 
minimal automata, bisimilarity is equivalent to isomorphism, while for deterministic 
automata, bisimilarity is equivalent to equality of trace sets. 

Definition 4.2. Let A and B be FSMs. A relation c 5 ^ x % is a bisimulation on 
A and B iff 

■ R{s\ , S2) and 5 'i implies that there is a € Sa such that S2 s'2 

and R{s'^,s'2), 

■ R{s\ , S2) and S2 4 implies that there is a s'^ e Sa such that s\ -^a * 5 'i 
and 

A and B are bisimilar, notation AnB, \f there exists a bisimulation /? on ^ and B 
such that s^). We call two states s\,S2 € Sa bisimilar, notation S[ S2, if 
there exists a bisimulation RonA (and . 4 ) such that R(s\ , 52). The relation tlA is an 
equivalence relation on 5 ^; a bisimulation class of A is an equivalence class of Sa 
under □ 

The main ingredient of Chow’s test suite is a characterizing set for the specification, i.e. , 
a set of input sequences that distinguish inequivalent states by inducing different output 
behavior from them. In our case, two states are inequivalent if they are non-bisimilar, 
i.e. have different trace sets. In the presence of symmetry we will need a characterizing 
set not for the entire specification automaton but only for a kernel of it. However, a 
kernel need not be input enabled, so two inequivalent states need not have a common 
input sequence that distinguishes between them. Instead we will use a characterizing 
set that contains for every two states of the kernel that are inequivalent in the original 
specification automaton, an input sequence that these states have in common in the 
specification and distinguishes between them. 

Constructing distinguishing sequences in the specification automaton rather than 
in the smaller kernel is of course potentially as expensive as in the setting without 
symmetry, and may lead to large sequences. However, if the number of states of the 
kernel is small we will not need many of them, so test execution itself may still benefit 
considerably from the restriction to the kernel. Moreover, we expect that in most 
cases distinguishing sequences can be found in a well marked out subautomaton of the 
specification that envelopes the kernel. 
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Definition 4.3. A test pair for a Mealy machine ^ is a pair (/C, W) where /C is a 
kernel of A and is a set of input sequences of A such that the following holds. For 
every pair of states s, s' e Sx: such that s s' , ^ contains an input sequence % such 
that outcome s) ^ outcome s'). □ 

The proof that Chow’s test suite has complete fault coverage crucially relies on the 
assumption that (an upper bound to) the number of states of the black box implementa- 
tion is correctly estimated. Since specification and implementation are also assumed to 
have the same input sets and to be input enabled, this is equivalent to a correct estimate 
of the number of states of the implementation that can be reached from the start state 
by an input sequence from the specification. Similarly, we will assume that we can 
give an upper bound to the number of states of the black box that are reachable from 
the start state by an input sequence from the kernel of the specification. We call the 
subautomaton of the implementation generated by these states the image of the kernel. 

Technically, the assumption on the state space of the black box is used in [7] to 
bound the maximum length of distinguishing sequences needed for a characterizing 
set for the implementation. Since, like the kernel, the image of the kernel need not be 
input enabled, it may be that distinguishing sequences for states of the image cannot 
be constructed in the image itself. Thus, it is not sufficient to estimate the number of 
states of the image, but we must in addition estimate the number of steps distinguishing 
sequences may have to take outside the image of the kernel. 

Definition 4.4. Let A and B be Mealy machines with the same input set and let 1C be 
a kernel of A. A K-sequence is an input sequence ^ such that s^ A state s of 

B is called K-related if there exists a /C-sequence ? such that s^ s. 

We define imx:(B) as the subautomaton (5, E, £, s^) of B defined by: 

■ S = [s e \ s is /C-related} 

■ E = {(i-, a, s') e Ejs \ s, s' e S] 

■ S = {a e Sjg I 3 5, 5*'. (5, a, s') e E] 

■ 

□ 

Definition 4.5. A subautomaton B of a Mealy machine ^4 is (m i , m 2 )-self-contained 
in A when the number of bisimulation classes Q of A such that QCi Ss ^ 0 is mi, 
and for every pair of states s, s' of B such that s s', there exist input sequences 

fi, ^2 of A of length at most mi, m2, respectively, such that s =^5, s' =^5, and 
outcomej^{^\^ 2 ^ s) ^ outcome s'). □ 

The next lemma is a generalization of [7]’s Lemma 0. 

Lemma 4.6. Let A and B be Mealy machines with the same input set / and let (/C, W) 
be a test pair for A. Let C = imjc(B). Suppose that: 

1. C is (mi, m2)-self-contained in B. 

2. W distinguishes between n bisimulation classes QofB such that QC\Sc ^0^ 




345 



Then for every two states 5 and s' of C such that s 5-', /'"i " W distinguishes 
s from s'. 

This result allows us to construct a characterizing set Z = W for the image 

of the kernel in the implementation. The test suite resulting from the W-method consists 
of all concatenations of sequences from a transition cover P for the specification with 
sequences from Z. 

Definition 4.7. A transition cover for the kernel of a Mealy machine ^ is a finite 
collection P of input sequences of A, such that € e P and, for all transitions s s' 

of /C, P contains input sequences ^ and ^ i such that s^ =^jc s. □ 

Now follows the main theorem. 

Theorem 4.8. Let Spec and Impl be Mealy machines with the same input set /, and 
assume (~, 0'^) is a symmetry on Spec such that Impl is closed under Let (/C, W) 
be a test pair for Spec. Write C = Suppose 

1. The number of bisimulation classes Q of Spec such that Q f) Sjc ^ n. 

2. C is (mi,m 2 )-self-contained in Impl. 

3. For all a 6 P and r € W 

outcomespeciP r, = outcomeimpi(a r, 



Then Spec Impl. 

5 PATTERNS 

In this section we describe symmetries based on patterns. A pattern is an FSM, together 
with a set of permutations of its set of actions, so-called transformations. The FSM 
is a template for the behavior of a system, while the transformations indicate how this 
template may be filled out to obtain symmetric variants that cover the full behavior of 
the system. 

In [18] an interesting example automaton is given for a symmetric protocol, repre- 
senting the behavior of two peer hosts that may engage in the ATM call setup procedure. 
This behavior is completely symmetric in the identity of the peers. An FSM represen- 
tation is given in Figure 2. Here, !< action >(i) means output of the ATM service to 
caller i, and ?<action>(i) means input from caller i to the ATM service. So, action 
?set_up(l) denotes the request from caller 1 to the ATM service, to set up a call to caller 
2. A set_up request is followed by an acknowledgement in the form of calLproc if the 
service can be performed. Then, action conn indicates that the called side is ready 
for the connection, which is acknowledged by conn_ack. A caller may skip sending 
calLproc, if it can already send conn instead (transition from state 3 to 5 and from 10 
to 12 in Figure 2). 

Here, a typical template is the subautomaton representing the call set up as initiated 
by a single initiator (e.g. caller 1), and the transformation will be the permutation of 
actions generated by swapping the roles of initiator and responder. Such a template is 
displayed in Figure 3. 
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Figure 2 The ATM call setup protocol Figure 3 A template 



In the example of Section 6, featuring a chatbox that supports multiple conversa- 
tions between callers, the template will be the chatting between two callers, while the 
transformations will shuffle the identity of the callers. 

The template FSM may be arbitrarily complex; intuitively, increasing complexity 
indicates a stronger symmetry assumption on the black box implementation. 

To define pattern based symmetries, we need some terminology for partial functions 
and multisets. If / : A -> B is a partial function and a e A, then f(a) i means that 
f(a) is defined, while f(a) t means that f(a) is not defined. A multiset over A is 
a set of the form {(ai, ni), . . . , (ak, rik)] where, for 1 < / < A:, ai is an element of 
A and rii e N denotes its multiplicity. We use [f(x)\ cond(x)] as a shorthand for the 
multiset over A that is created by adding, for every single x € A, a copy of f(x) if the 
condition cond(x) holds. 

Definition 5.1 (Patterns). A pattern Visa, pair (T, FI) where T is an FSM, called the 
template of V, and II is a finite set of permutations of 'Zj', which we call transforma- 
tions. 

Given a sequence (/i, . . . , /n) of (partial) functions /i, . . . , /n : II Ej-, we 
denote with exec({f\ , . . . , /n), tt) the sequence of edges obtained by taking for each 
function fi,0 <i <n, the edge e (if any) such that fi(7t) = e. □ 

In the remainder of this section, we fix an FSM A and a pattern V = (T, 0). 

Below we will define how V defines a symmetry of the behavior of an FSM A. Each 
transformation ;r € II gives rise to a copy Jt(T) of T obtained by renaming the actions 
according to tt . Each such copy is a particular instantiation of the template. Intuitively, 
the trace set of A is included in the trace set of the parallel composition of the copies 
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7 t(T), indexed by elements of II, with enforced synchronization over all actions of 
A. Using that traces of A are traces of the parallel composition, we will define the 
symmetry relation on traces in terms of the behavior of the copies and permutations of 
the index set O. 

The following definition rephrases the inclusion requirement above in such a way 
that the relation 2:: and a representative function for it can be formulated succinctly. In 
particular, if A is the parallel composition of the copies of T, the requirement in this 
definition apply. 

Definition 5.2. Let cr =a\-anbem element of (5]^)*. A covering of a by P is a 
sequence (/i , . . . , /n) of partial functions /i : O Ej- with non-empty domain such 
that for every n eU and 1 < / < n: 

1. If fi(7t) = e then Oi = 7t(act(e)). 

2. The sequence exec({f\ ft), n) induces an execution yi of T. 

3. If the sequence trace{yi-\) Oi is a trace of tx{T) then /i (tt) 4.. 

We say that V covers a if there exists a covering of o* by 'P. 

We call V loop preserving when the following holds. Suppose a\ ai 6 traces{A) 
is covered by (/i , . . . , , . . . , gm) and 02 is a looping trace. Then for all tt € 11, 



last(exec({fu • . • , /«), tt)) = last{exec((fu gi, , gm), tt)) 



□ 

Intuitively, these requirements mean the following. The ‘non-empty domain’ require- 
ment for the partial functions /, ensures the inclusion of the trace set of A in the 
trace set of the parallel composition of copies of T. Requirements 1 and 2 express 
that a covering should not contain ‘junk’. Requirement 3 corresponds to the enforced 
synchronization of actions of the parallel composition. 

Two traces cr and r of the same length n that are covered by P, are variants of each 
other if at each position / , 1 <i < n, of a and r the following holds. The listings for 
a and r, respectively, of the copies 7t{T) that participate in the action at position /, the 
states these copies are in before participating, and the edge they follow by participating, 
are equal up to a permutation of 11. Then, two traces of the same length are symmetric 
iff they are either both not covered by P or are covered by coverings that are variants 
of each other. 

Definition 5.3. Let a and r be elements of (E^)”, which P covers by cov\ = 
(/i , • • • , /n> and C0V2 = (gi , . . . , gn), respectively. Then cov\ and covi are said to be 
of each other if for every 1 < / < n, [fi{n) | tt e O] = [g/(7r) | tt G O]. 
We define the binary relation on (E^)* by: 

or r A |a| = |r| 

A V both or and r are not covered by P 
V P covers a and r by variant coverings 

It is easy to check that cip is an equivalence relation. As in Section 3, we will write 
[a] for the equivalence class of o and 2;: instead of □ 
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An important special case is the following. Suppose A consists of the parallel compo- 
sition of components C/, indexed by elements of a set /, that are identical up to their 
ID (which occur as parameters in the actions). Let a and r be traces of A. If there 
exists a permutation p of the index set I such that for all indices i e 1, a induces (up 
to renaming of IDs in actions) the same execution of Q as r induces in Cp{i), then a 
and r are symmetric. 

Now we define a representative function for We assume given a total, irreflexive 
ordering < on Such an ordering of course always exists, but the choice for < may 
greatly influence the size of the kernel constructed for a symmetry based on V. 

Definition 5.4. Let < be a total, irreflexive ordering on E^. This ordering induces a 
reflexive, transitive ordering < on traces of the same length in the following way: 

a a <br^a<b\/ (a = bAcr <x) 

We define as the least element of [a] under <. □ 

Given the definition of it is reasonable to demand that every trace of A is covered 
by V. We will also need the following closure property. We call a binary relation R 
on (E^)* persistent on A when R(a, r) and a a e traces(A) implies that there exists 
an action b such that R(cx a, x b). 

The next result allows us to use the pattern-approach for computing a kernel. In our 
example of the ATM switch, we have computed the kernel from the FSM in Figure 2, 
using the symmetry induced by the template in Figure 3 and an ordering < that obeys 
the relation ?set_up(l) < ?set_up(2). Not surprisingly, the resulting kernel is identical 
to the template. 

Theorem 5.5. Suppose P is a loop preserving pattern on A and let < be a total, 
irreflexive ordering on E^. Let O'" be as in Definition 5.4. Suppose every trace of A 
is covered by V, A is closed under and ~ is persistent on A. Then (~, O'") is a 
symmetry on A. 

6 EXAMPLE: TESTING A CHATBOX 

In this section we report on some initial experiments in the application of symmetry 
to the testing of a chatbox. This example was inspired by the conference protocol 
presented in [23]. Part of the test generation trajectory was implemented: we used 
the tool environment OPEN/CiESAR[14] for prototyping the algorithm Kernel from 
Section 3. We work with a pattern based symmetry (Section 5) and apply the test 
derivation method from Section 4. 

A chatbox offers the possibility to talk with users connected to the chatbox. After one 
joins (connects to) the chatbox, one can talk with all other connected users, until one 
leaves (disconnects). One can only join if not already present, and one can leave at any 
time. For simplicity, we assume that every user can at each instance talk with at most 
one user. Moreover, we demand that a user waits for a reply before talking again (unless 
one of the partners leaves). Finally, we abstract from the contents of the messages, and 
consider only one message. The service primitives provided by the chatbox are thus 
the following; Join, Leave, DReq, and DInd, with the obvious meaning (see Figure 4). 
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Mser^ uscr^ uscr^; uscr^ uscr^ user^; 

Join Leave DReq DInd 




Figure 4 The chatbox protocol service 



For lack of space, we do not give the full formal specification of the chatbox or its 
template. 

What we test for is the service of the chatbox as a whole, such as it may be offered by 
a vendor, rather than components of its implementation, which we (the “customers”) 
are not allowed to, or have no desire to, inspect. 

The symmetry inherent in the protocol is immediate: pairs of talking users can be 
replaced by other pairs of talking users, as long as this is done systematically according 
to Definitions 5.2 and 5.3. As an example, the trace in which user 1 joins, leaves and 
joins again, is symmetric to the trace in which user 1 joins and leaves, after which user 
2 joins. The essence is that after user 1 has joined and left, this user is at the same 
point as all the other users not present, so all new join actions are symmetric. Note 
that this symmetry is more general than a symmetry induced solely by a permutation 
of actions or IDs of users. Thus the template T used for the symmetry basically 
consists of the conversation between two users, including joining and leaving, while 
the transformations tt in the set O shuffle the identity of users. We feel that it is a 
reasonable assumption that the black implementation offering the service indeed is 
symmetric in this sense. 

We have applied the machinery to chatboxes with up to 4 users. We also considered 
a (much simpler) version of the protocol without joining and leaving. Still, a chatbox 
with only 4 users and no joining or leaving already has 4096 reachable states. 

We start the test generation by computing a kernel for these specifications. Our 
prototype is able to find a significantly smaller Mealy machine as a kernel for each 
of the models, provided that it is given a suitable ordering < (see Definition 5.4) on 
the actions symbols for its representative function. The kernels constructed consist of 
interleavings of transformations of the pattern, constrained by the symmetry and the 
ordering <. 

For instance, in a chatbox with 3 users and no joining and leaving, we take the 
ordering < defined as follows. “Sending a message from i\ to j\" < “sending a 
message from i 2 to 72” if ih < h) or if (/i = (2 and j\ < 72)^ and “sending a reply 
from i\ to 71” < “sending a reply from (2 to 72” if (ii > h) or if (/i = h and j\ > 72). 

Using this ordering, the kernel only contains those traces in which first messages 
from user 1 are sent, then messages from user 2 and finally messages from user 3, while 
the sending of replies is handled in the reverse order. Each trace with different order of 
sending messages can then be computed from a trace of this kernel, which is exactly 
what Theorem 3.3 states. 
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Our experiments so far have revealed that for chatboxes with joining and leaving, 
the kernel is approximately half the size. When considering chatboxes without joining 
and leaving, the size of the kernel is reduced much more. Of course, the algorithm 
should be run on more and larger examples to get definite answers about possible size 
reduction. 

Given the computed kernels, we can construct test pairs by determining for each 
kernel a set of input sequences W that constitutes a characterizing set for the kernel (as 
defined in Definition 4.3). Although this part has not yet been automated, it is easily 
seen by a generic argument that for every pair of inequivalent (non-bisimilar) states 
very short distinguishing sequences exist. It is easy to devise a transition cover for a 
kernel, the size of which is proportional to the size of the kernel. 

As shown in Theorem 4.8, the size of the test suite to be generated will depend on the 
magnitude of two numbers m\ and m 2 , indicating the search space for distinguishing 
sequences for the image of the kernel in the implementation. This boils down to the 
following questions: (1) What is the size of the image part of the implementation for 
this kernel? (2) What is the size of a minimal distinguishing experience for each two 
inequivalent (non-bisimilar) states in the image part of the implementation? (3) How 
many steps does a distinguishing sequence perform outside the image of the kernel? 
These questions are variations of the classical state space questions for black box 
testing. For practical reasons, these numbers are usually taken to be not much larger 
than the corresponding numbers for the specification. 

The algorithm Kernel (see Figure 1) was implemented using the OPEN/CiESAR [14] 
tool set. An interesting detail here is that the algorithm uses two finite state machines: 
one for the specification that is reduced to a kernel, and one for the template of the 
symmetry, which is used to determine (as an oracle) whether two traces are symmetric. 
To enable this, OPEN/CiESAR interface had to be generalized somewhat so that it is 
now able to explore several labeled transition systems at the same time. We have the 
experience that Open / Caesar is suitable for prototyping exploration algorithms such 
as Kernel. 

7 FUTURE WORK 

We have introduced a general, FSM based, framework for exploiting symmetry in spec- 
ifications and implementations in order to reduce the amount of tests needed to establish 
correctness. The feasibility of this approach has been shown in a few experiments. 

However, a number of open issues remain. We see the following steps as possible, 
necessary and feasible. On the theoretical side we would like to (1) construct algorithms 
for computing and checking symmetries, and (2) determine conditions that are on the 
one hand sufficient to guarantee symmetry, and on the other hand enable significant 
optimizations of the algorithms. On the practical side we would like to (1) generate 
and execute tests for real-life implementations, and (2) continue prototyping for the 
whole test generation trajectory. 
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Abstract 

This paper presents first steps towards automatic generation of distributed 
tests. We first define a characterization of the tests for which the property of 
unbias is preserved by the existence of an asynchronous environment. Then, 
starting from a centralized test case, we propose a method to derive automat- 
ically its corresponding distributed test case in an asynchronous environment. 
We prove that the generated distributed test case is not biased, it tests the 
same behaviors of an implementation and has the same testing power as the 
centralized test case. 
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1 INTRODUCTION 

In the context of black box conformance testing, an implementation under test 
(lUT) is tested in order to obtain the conviction that its behavior conforms 
with its specification. The testers stimulate the lUT by sending messages on 
points of control and observation (PCOs) and observe on these same PCOs 
the reactions of the lUT. Within sight of the reactions, a verdict (Fail, Pass 
or Inconclusive) is emitted. More recently, the conformance testing method- 
ology has been formalized [1, 2, 3] and brought more confidence in the testing 
activity. Most of works in this field using formal methods concentrated on the 
production of a centralized single tester and make the implicite assumption 
of synchronicity between the tester and the lUT [4, 5]. In practice however, 
one cannot always avoid taking into account the test environment intercalated 
between the tester and the lUT. The most frequent example is that of remote 
testing architecture in which the tester reaches the lUT through a network 
connection. In this case, PCOs can be seen as composed of two FIFO queues, 
for each direction of the interaction: one speaks then about asynchronous in- 
teraction between the tester and the lUT. In the prolongation of this concept. 
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we propose to aim at a test architecture in which several testers coexist and 
interact in an asynchronous way not only with the lUT but also between them 
to coordinate the testing activity. It is about a generalization of the multi- 
party testing technique which benefits from the various possibilities offered 
by the introduction of concurrency into TTCN [6]. By considering that the 
lUT itself could be distributed, we are in the general context of distributed 
testing of a distributed architecture, illustrated by figure 1. To face up to the 
problem of the design of such testers, we distinguish several subproblems. 

The first main problem is that of the asynchronism on PCOs. The possibil- 
ity of disorder on the observations collected on different PCOs as well as the 
possible collision on a PCO between a stimulus and an observation makes dif- 
ficult the design of testers. During the examination of existing test suites, one 
realizes that these are the main reasons of non- validity of some tests: precisely 
a correct test not rejecting conformant implementations in a synchronous en- 
vironment can be biased (i.e. it rejects a conformant implementation) when 
it is carried out in an asynchronous environment [7]. It is thus significant to 
know if a test is correct in an asynchronous environment. We will show that 
contrary to what is suggested in the ISO/9646 methodology [6, 8] with the 
concept of generic abstract test case, independent of the testing environment, 
this question depends on the specification of the system to be tested. 

The second main problem is to design the distributed tester (a system of 
parallel testers) and their coordination procedure. We propose to start from 
a centralized test case and automatically to produce by compilation the com- 
municating testers. Insofar as the initial centralized test case is sequential and 
describes a set of behaviors to be tested, we try to reproduce in a distributed 
way, exactly the same set of behaviors, by exploiting some ideas from protocol 
synthesis [18]. The possible concurrencies in the whole distributed test come 
from the desynchronization between the lUT and the testers and between lo- 
cal actions of the testers. To extract the potential concurrency of the initial 
test case is a prospect for our approach. This should impact the generation 
phase of test cases from formal specifications (as advocated in [15] using event 
structures), or demand some causal information at runtime (as suggested by 
[16, 17]). 




Figure 1 Distributed testing in an asynchronous environment 
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In order to found our approach mathematically, we use the standard model 
of input-output transition systems to represent all the objects (testers, spec- 
ifications and lUTs) involved in the conformance testing. The notations and 
models used in this paper are described in the section 2. In section 3, we pre- 
cisely state the condition under which the property of unbias of the test is pre- 
served by the existence of an asynchronous environment. We show that it can 
be computed starting from the specifications of the lUT and the tester. Then 
we propose, in section 4, a compilation rule which produces the distributed 
tester starting from an initial centralized test case. The difficult question is 
the resolution of distributed choices. We show that under the assumption of 
an underlying service of election, one obtains a system whose traces reduced 
to the events on PCOs are the same ones as the traces defined by the central- 
ized test case. A proof of the correctness of the distributed test case is given 
followed by an example of distribution. Concluding remarks and future works 
are presented in section 5. 



2 MODELS FOR CONFORMANCE TESTING 

In this section we describe the models used for the description of the different 
objects involved in the generation of test cases. 



2.1 Input- Output labelled transition systems 

The models used are all based on Input-Output Labelled Transition Systems 
(lOLTS) in which input and output actions on input and output ports are 
differentiated because of the asymmetrical nature of the testing activity. 

Definition 21 An lOLTS is a tuple M={Q^, P/, Af, A^,T^, where 
is a set of states, is the initial state, Pf and Pq are finite 

sets of input and output ports, Af and Aq respectively are finite input and 
output alphabets, A^ = Pfi x {?} x Af U Pq x {!} x Aq is the alphabet of 
observable actions constructed from the sets of input- output ports and input- 
output alphabets, r ^ A^ denotes an internal action, C x A^U{r} x 
is the transition relation. We note q for {q, a, q') € T^. 

An lOLTS is a particular Labelled Transition System (LTS). Consequently 
we adopt the following standard notations of LTS. 

Let Oi E A^, fueA^U {r}, a e q,q',qi G Q^, 

• q q' = q^q^ ^^^,qn= € [l,n],gi_i 4 qi, 

• q — >■ =^^q ,q — >• q and q q'=^not{q — )• ), 

• q^ q' -c.q = q' ox q ^ q' and q^ q' 3gi, 92 , 9 ^ Q 2 ^ 

• q “5=$’* q' 3qo = q,qi-..,qn= q' ,'ii € [l,n],gi_i ^ qt, 
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• enable{q) {a e \ 3q' and q q'} is the set of observable actions 
possible in g, 

• In{q) {a € Aj I 3pi G Pf^pi?a G enable{q)} is the set of possible 
inputs in q and Out{q) [a £ A^\ 3po G PQ.Pola G enable{q)} is the 
set of possible outputs in q^ 

• q after a {q' E \ q =^m <i'] is the set of reachable states from q by 
the sequence of observable actions cr, 

• traces{q) =a {o' G {A^)* \ q after cr 7 ^ 0 } 

• if a G A^ is an observable action, we note a its mirror action defined by 
p\a = p?a and p?a = p\a. This notation is extended to sequences of actions. 

When needed, we will identify a transition system with its initial state. 



2.2 Specifications, implementations, test cases and 
conformance 

A specification is modelled by an lOLTS 5 = (Q^,P/,Pq, Af, 

If we want to model the absence of output in a specification, as in [9], we can 
model it by adding a loop with output 5 G Aq in each state where no output 
and no r transition is possible. Here, for the sake of simplicity, we will not 
distinguish 6 from other outputs. 

Though an implementation of S is not necessarily a transition system 
(it may be a physical system), as in all testing theories, we have to rea- 
son formally about it and model its behaviour. As it is only considered 
by its interactions with the environment, it is also modelled by an lOLTS 
I = with P} = Pf and = P^ and A} C A}, 

Aq C Aq. We will suppose that an implementation I can never refuse an 
input: Vcr G (A^)*,/n(/ after a) = A\ 

A test case is a set of sequences of actions describing all the interactions oc- 
curring between an lUT I and a tester which wants to verify that I conforms to 
its specification S. A test case is an lOLTS T = PJ^Pq, A], Aq, T'^, 
such that AJ = Aq i.e. every possible output of the implementation must be 
considered as an input of the test case, Aq = Af i.e. a test case should only 
send outputs that are waited by the system as described in the specification, 
{pass, fail} G with enaWe(pass) = enable{fail) = 0, T is controllable i.e. 
in each state, either an output is enabled or all inputs are enabled which is 
formally described by Vcr G (A'^)*,/n(T after cr) = A] or 0, the state fail 
is directly accessible only by inputs i.e. Vg G G A'^,g fail => 

G P/,a G AJ,a = pi a *. Notice that we do not suppose that testers are 



*In a way identical to specifications, the absence of output is modeled by the output 5 G Aq. 
*In practice however Aj = A^ is unknown. Thus only inputs not leading to fail can be 
mentioned, the other inputs are implicitly leading to fail or are mentioned by ? otherwise 
with verdict Fail, like in TTCN. 
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deterministic as it would be to strong for distributed testers. Anyway, we only 
consider the traces of testers. 

We consider a conformance relation quite similar to those in [10, 11, 9]. 
Informally, the conformance relation states that after a trace of the speci- 
fication, outputs produced by the implementation must be foreseen by the 
specification. This authorizes the fact that outputs of the environment which 
are not accepted by the specification may be accepted by the implementation. 

Let 5 and I be two lOLTS describing a specification and an implementation, 
I ioconf 5 =A Vcr G traces{S), Out{I after a) C Out{S after a) 

Remark: traces{I) C traces^!') => (/' ioconf S I ioconf 5). 

But traces{S) C traces{S') (/ ioconf S => / ioconf S') 
and traces{S) C traces{S') ^/=> (7 ioconf S' =» I ioconf 5). 



3 CHARACTERIZATION OF UNBIASED TEST CASES 

Our goal is to distribute test cases without loss of observation power. But be- 
fore studying this problem we have to define what kind of test cases we want 
to distribute. So we start by giving a characterization of unbiased test cases 
with respect to a specification. This characterization supposes a synchronous 
communication between the tester and the implementation. As we want to 
distribute test cases for asynchronous architectures, we extend this character- 
ization to testers which communicate asynchronously with implementations. 

3.1 Synchronous testing 

The synchronous application of a test case to an implementation is defined as 
a parallel composition of the test case T and the implementation I. 

T^T' T^T' I^I' 

T\UI^T\\sI> T1U/-T'|U/ TWsI^T'WsI' 

We can now define test failure and unbiased test cases with respect to ioconf 
and a given specification: 

Definition 31 T fails 7 =a 37', 3(7,T||J ^ fail|l,7' 

T is unbiased w.r.t. S =a V7,T fails 7 => not{I ioconf 5) 

Now the following proposition gives a characterization of unbiased test cases 
w.r.t. a specification in a synchronous environment. It says that after each 
trace of the test case leading to a state where an input is allowed, each possible 
output of the specification after the same trace should be taken into account 
and should not lead to a fail verdict. 
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Proposition 31 T is unbiased w.r.t S 4==> 

Vcr e traces{T) s,t. In{T after a) i=- 0, Out{S after a) C In^fau{T after a) 
with In^faiiiT') = {a G In{T') \ 3p,T' T" A fail ^ T"} 

Proof. Let T be a test case such that Vcr G traces{T) s.t. /n(T after a) 7 ^ 0, 
Out(5 after cr) C In^f^u{T after cr). We have to prove that T is unbi- 
ased w.r.t. S. Suppose that for some /, T fails I . By definition, fail ver- 
dicts are only given on inputs of T (i.e. outputs of I), thus a trace lead- 
ing to a fail verdicts ends with an input of T. T fails I can be written as 

37i,/',3Ti,3(t',3p € PJ,3a G A] s.t. T\\J ^ Ti\\Ji fail||,7'. Thus 
a ^ In^f^ii{T after a\) and as Out{S after (Ji) C In^fau{T after di), 

we also have a ^ Out{S after di). But we have / S 7i /' which 

implies a G Out{I after di). Consequently, 3di G traces{S),3p,3a,a G 
Out{I after di) A a ^ Out{S after di) which proves that not (/ ioconf S) 
and thus T is unbiased w.r.t. S. 

Now suppose that 3d G traces{T), In{T after cr) and Out{S after d) 2 
In^faii{T after or). Then 3a e A], 3p, (5 after d =^) A (T after a fail). 

Let I = a.pla. Clearly we have I ioconf S. But as T\\sl fail ||50 we get 
T fails I and T is biased w.r.t. 5. □ 

Remark: Proposition 31 exactly characterizes unbiased test cases with re- 

spect to a specification. This is defined for a particular conformance relation 
ioconf and with some hypothesis on the structure of test cases. But ioconf 
seems to be exactly what manual test developers have in mind and the hy- 
pothesis made on test cases are weaker than those made on manual test cases. 

In the context of automatic generation of test cases it is important to ensure 
that test cases are unbiased and this kind of characterization should be verified 
by tools. Notice that the prototype tool TGV [3] ensures this by construction. 



3.2 Asynchronous testing 

Before extending the preceding characterization to asynchronous testing, we 
have to define what is asynchronous testing. It is defined from synchronous 
testing by considering a transformation of the specifications and the imple- 
mentations by a queue context like in [ 12 ]. 

Let M = Pf , be an lOLTS. We define an lOLTS 

A{M) which models the behavior of M in an asynchronous environment. 
A{M) = with 

• g-(“) = g-xripePM xRpepM Ag* and =< M, (e • • • e), (e • • ■ e) > 
■•Recall that In{T') = Aj or 0 due to the controllability property. 
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• = p/ and = p^, and = A^. 

• pA(M) jg described by the following operational rules defined for all q, o' € 
g“,o € Ay-,6 € Ag,p„ € Pf,Poi € %: 



Rl 

R2 

R3 

R4 

R5 



< 9.{PU •• -Pifc =«'••■). (Poi •••) >’’‘-^“a(M)< 9,(Pii •■•Pi'fc ~w.a-- -),(Poi ■ ■ •) > 

PO z 

< 9,(pii •• -))(Poi • "Voi =b.w--) > 4 a(m)< 9, (pii • • •)» (poi • • -poi = It; - • •) > 

Q ->M q' 

< qAph -■)^POi •••) >-^A(M)< 9',(pii •••).(Poi •••) > 

Plfcja , 

Q M Q 

< 9, (Pu •••Pi*; = a.w---),(poi •••) >-^a(M)< 9'.(Pu •••Pi* =w-- -),(Poi • • •) > 

PO(-^ / 

g 4 M g 

< g.(pii -‘)APoi -'Poi=w-’) >4a(m)< g',(pu •• ^.(Poi - ’Poi =w.b--) > 



Remark: The first rule allows the lOLTS A{M) to receive any input in any 

state. This leads to an infinite states lOLTS. When this transformation is used 
to model the behaviour of a specification in an asynchronous environment in 
order to derive test cases, this of course poses algorithmic problems. Thus 
it is reasonable to limit the behaviour of tne specification in order to derive 
test cases. An example of limitation consists in allowing the environment to 
send only messages that are possibly waited and to limit the sum of lengths 
of input queues to 1. In this case Rl could then be replaced by: 



< g,(e---e---),(poi •••) >^^‘"a(m)< g,(e--'P/fc = a--*)>(POi * • *) > 



As in [13], we define the conformance of an implementation with respect to a 
specification in an asynchronous environment as the conformance of the imple- 
mentation in its asynchronous environment with respect to the specification 
in the same asynchronous environment. This directly leads to the definition of 
test failure and unbias in an asynchronous environment and gives a corollary 
of Proposition 31: 



Definition 32 Let I be an implementation of a specification S, T a test case. 
I ioconf^ 5 =A A{I) ioconf A{S) 

T fails^ I 34', 3a,T\\sA{I) =4 fail 1|,4'. Thus T fails^ I = T fails A{I). 
T is unbiased w.r.t S in an asynchronous environment V/,T fails^ I => 
not{I ioconf^ 5). 

It is equivalent to say that test case T is unbiased with respect to 4(5). 



Corollary 31 T is unbiased w.r.t. S in an asynchronous environment <=> 

V(7 e traces{T) s.t. In{T after a) ^ 0, Out{A{S) after a) C In^fan{T after a) 

with In^fMT') = {a € In(T)\3p, V T" A T" # fail}. 

This corollary characterizes a class of test cases that are unbiased in an asyn- 
chronous environment. It is also easy to prove that an unbiased test case in 
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an asynchronous environment is also unbiased in a synchronous environment. 
This uses the fact that traces{M) C traces{A{M)) which relies on construc- 
tion rules of A{M) and the property that if traces{S) C traces(S') then, if 
T is unbiased w.r.t. S' then T is also unbiased w.r.t. 5. The converse is of 
course false as was already noticed in [13]. 



4 AUTOMATIC DISTRIBUTION OF TEST CASES 

In this section we develop the rule used to automatically distribute a central- 
ized tester. Then, we give the correctness proof of that rule wich implies that 
the unbiased criterion is preserved by the distribution rule and that the dis- 
tributed tester rejects the same lUTs as the original centralized tester. Some 
additional notations are needed. Let T be an lOLTS, q and a e A'^: 

• pT ^ pj y pr 

• if a = p?a or a = p!a, where p € P'^, then port{a) =a P- 

• p^enable{q) =a {p G P'^ | 3a G enable{q) port{a) = p} 

• if a = p?a then present{a) is a predicate which is true if the label a is 
present in the input queue associated to the port p, and it is false otherwise. 
If a = pla then present{a) is true. 

• The asynchronous parallel composition of Ti, •••, Tn is denoted by \\asTi = 

\\sA{Ti) where an output port of a tester may be unified with an input 
port of another tester to make the coordination possible. We also note 
DT = WasTi set of global states of \\asTi. A global state 

Q G is a tuple (gi, • • * ? A, * * * ? fn), where qi is the state of Ti and 
A is the state of the input and output queues of Ti. 

Starting from a test case T modellized by an lOLTS, the problem is to 
synthesize a set of asynchronously communicating lOLTSs {Ti, • • • , Tn} where 
n is the number of PCOs of T. The initial state of each tester Ti is qinit- For 
sake of clarity, we have considered that each tester is associated with each 
PCO. The extension to a general PCOs mapping is straightforward. In the 
following we consider that only the actions of A'^ are observable. 



4.1 Distribution rule 

We present here bellow the rule used to automatically distribute a centralized 
tester. The result is a set of communicating testers. Starting from a pattern 
of the centralized tester defined by a state q with one or several outgoing 
transitions, the rule [Rl] synthesizes a set of transitions of the distributed 
tester. These transitions can be decomposed into three parts. The part (A) 
defines the transitions of the testers Ti associated to the ports involved in the 
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Figure 2 Distribution rule (a) Tester Ti \ i e p.enable{q) (b) Tester Tk 
k ^ p.enable{q)^ k £ X {c) Tester Tk \ k ^ p^enable{q) U X 



outgoing transitions of g, namely p-enable{q) (see Figure 2 (a)). The part (B) 
defines the testers Tk which are not associated to the ports oi p^enable{q) and 
must receive a synchronization message from Ti (see Figure 2(b)). The part 
(C) concerns the testers which are not associated to the ports of p-enable{q) 
and do not require a synchronization message from T{ (see Figure 2 (c)). 

qeQ- 

[Rl] 

Vi G p-enable{q) Va G enable{q) | port{a) = i, q — qi • 

present{a) CS\req{a) CS?resp{a) a X\sync{q\) 

q > Ti qa\ > Ti qa2 > Ti QaS “>Ti ^a4 > Ti qi 

f ^ enable{q) \ port{b) ^ i, q At q2, i ^ p.enable{q2) : 

\ CS?resp(b) CS?resp{b) 

Qa2 ^ Ti Q2 Q ^ Ti q2 

Vc G enable{q) | port{c) = j ^ q At ^3, i G p.enable{q3) : 
CS?resp{c) CS?resp{b) Tjlsync{qz) 

, qa2 ^ Ti ^c3 Q ^ Ti Qc3 QcZ ^ t, QZ 

(B) { Vt i pjmaUe{q), k e X : , ,,, „ 

(^) { Vfc ^ pjenable{q), k ^ X : q 

where X = {Tj | i 7^ i, j G p.ena6/e(^i)}. 

A mapping function F is introduced between the states of the distributed 
tester and the states of the centralized tester T. The states provided by F are 
called observable states: F : |J^_^ — > Q'^. According to the rule [Rl]: 

F{qai) = F{qa2) = F{qaz) = F{qc 3 ) = F{q) = q and F{qa 4 ) = F{qi) = qi 
This function ensures that the observable state of a tester should change 
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Figure 3 Election Service 



only when the tester performs an observable action or when it receives a 
synchronization message. This function is introduced for correctness proof. 

The testers use an election service when they attempt to perform an ob- 
servable action (action of A^), The service accepts at least one request from 
the testers and delivers to all the testers the observable action which has 
been selected. The interaction of each tester with the election service is syn- 
chronous and it is done through a coordination port named CS. An abstract 
specification is given in Figure 3. The transition labelled by \\\aeAiCS?req{a) 
specifies all possible interleaving of the requests coming from the testers and 
concerning only with the actions of Ai (where Ai, - •• ,Ak are all possible sub- 
sets of A'^). This transition specifies an hypercube. The transition labelled by 
\\\ie[i,n](^ S\resp{a) is another hypercube which specifies the broadcasting of 
the selected* action among those of Af. 



4.2 Correctness proof 

We present in this section the correctness proof of the distribution rule. Our 
purpose if to prove that the asynchronous parallel composition of the syn- 
thezised testers (i.e, the distributed tester) is trace-equivalent to the central- 
ized tester. Under the assumption of an election service and reliable and FIFO 
communication channels between the testers, we start by proving two lemmas. 
The first one (Lemma 41) stipulates that when two successive observable ac- 
tions occur in the distributed tester, the observable state in which the second 
action is done is the same as the one reached by the first action. The observable 
state of a tester is provided by the mapping function F, This lemma implies 
that every trace of the distributed tester is a trace of the centralized tester. 
The second lemma (Lemma 42) states that if the centralized tester can do an 
observable action in a given observable state, the distributed tester could nec- 
essarily do the same action (possibly surrounded by one or several r- actions). 
This lemma implies that every trace of the centralized tester is a trace of the 
distributed tester. Using these two lemmas, we prove the trace-equivalence 
(Theorem 41). 



For sake of clarity of Figure 3, the selection is done using a function /. 
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Lemma 41 "iQ,U,V,W G Va,6 G such that Q -^dt U -^dt 
y -^DT 3q,x^w G Q'^ such that: q = F{qi) ^ = F{ui) = 

F{vi) -^T ^ = F{wj), where i = port{a)j j = port{b), qi and ui are states 
ofTi resp. in Q and U , Vj and wj are states ofTj resp. in V and W, and F 
is defined in Section 

Proof. Let Q, [/, F, VF G let a, 6 G such that: 

Q -^or U ^OT V -^DT W (1) 

Q -^DT u =>3Ti\i = port{a) and qi Ui => F{qi) F{ui) 
y -^DT W => 3Tj 1 j = port{b) and Vj '^j F{vj) F{wj) 

We should prove a first property (noted PI): 3q,x,w G such that q 
X 'w, and then a second property (P2): F{ui) = F{vj). 

From the sequence (1), we know that 3q, x e such that: q -%t x. Suppose 
that: G Q'^ such that q 2 ;, Va G enable{x), a ^ b. The rule 

[Rl] guarantees that in the distributed tester after the observable action a 
we cannot have 6, and this is in contradiction with (1). Therefore, (PI) is 
necessarily true. To prove (P2) we distinguish 2 cases: 

Case 1 {i ^ j): From the sequence (1), we can extract the following sequences 
of the testers Ti and Tj : 

qi ^Tj ^Ti (2) 




According to rule [Rl], and using (PI), among the r- actions of (3), there 
exists necessarily a reception of a synchronisation message {sync{x)). So, (3) 
can be written as follow: 





(5) 



The last transition of (4) is the reception of sync{x). Using the mapping 
function F to that transition, we have: F{u'^) F{u'-). By identification 

with F{qi) -^T F{ui), we obtain: F{uj) = F{qi) and F{u'-) = F{ui). Since 
the medium is supposed FIFO, another reception among the r-actions of (5) 
would imply another observation after a in (2) which is not true. So, there is no 
reception of synchronization message among the r-actions of (5). Furthermore, 
because of the election service, there is no action CS?resp{x) where x ^ b. 
So, (5) contains only the primitives which allow the election of b. From the 
definition of F, we deduce: F{uf) = F{vj), and consequently: F{ui) = F{vj). 
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Case 2 {i = j): From (1), we can extract the following sequence of the tester 

Tf. Qi -^Ti Vi vji. Since port{a) = port{b) = i and according 

to rule [Rl], there is no reception of synchronization message among the r- 

actions of that sequence. Furthermore, as in Case 1, the sequence Ui Vi 
contains only primitives which allow the election of 6. Consequently, from the 
definition of F, we have: F{ui) = F{vj) □ 

Lemma 42 \/q,v G Va G such that q v, 3Q,7 G such 

that' 3/i j * * * j /n Q — {qt ' ' ' T Qj fii ’ ' ‘ fn) ^ DT^ — fVj f I j ffi) . 

Prou/. By applying [Rl] to the transition q Vi we find the following 
sequences, respectively in Tj (where i = por^(a)) and in Tj ( where j ^ i): 

f a 

\ q qaS ^Ti qa4 

I r”* 

[ q — >Tj V where m G [1, 2] and j ^ i 
Using the above sequences we can find the following sequence in DT: 

3 ^ 

Q ~ (^) * ' * J /l ) * * * J fn) ^DT * * ' ) QaZi * * ‘ /l 7 ’ ' * ) fn) ^dt Q i 

Q “ (^7 * ’ * 7 Qa4i ' * * 7 ^7 /l 7 * ’ * 7 /n) ^DT (^7 * * * 7 ^7 * ’ ’ 7 ^7 /l 7 * ’ ’ 7 /n) Q J 

(2" -^dt (^7 • • • 7 *^^7 /i 7 • • • 7 /n) = ^- The last r* sequence contains the recep- 
tions of the synchronization messages which have been sent after the action a 
(because the medium is supposed to be FIFO and reliable). □ 

Theorem 41 If a distributed tester DT is synthesized from a centralized 
tester T using the rule [Rl], then: traces(DT) = traces{T). 

Proof. (C) Let a G traces{DT), a can be written as follow: a = r*air*a 2 • • • r*anT* 
where ai G Vz G [l,nj. From Qinit -^dt Q where Qinit.Q € 

3Uo, • • • , Un-\ 7 Qi 7 • • • 7 Qn € such that: 

Qinit Qn-l A Un^l ^ Qn = Q (6) 



From (6), 3Tk^ where ki = port{ai) such that: qk^ = qinit 
ql ^ , where and q\^ are the states of the tester Tk^ respectively in the global 
states Uq and Qi. Using the mapping function P, we get the first transition in 
T: F{ul^) = qinit F{qlJ (the r-actions from q^t to ul contains only 
the primitives which allow the election of a\ that is why F{u^J = qinit)- By 
applying the Lemma 41 to the sequence (6), we obtain: 

Vi e [1, n] Fiqi ~\ ) = F{ql ) 

where fcj = port{ai). This implies that 0102 - ••o„ € traces{T) and conse- 
quently, traces(DT) C traces(T). 
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(D) Let cr € traces{T), 3qi, ■■■ ,qn 6 Q'^ 3ai, • • • , a„ G such that: a = 
and qtnit 9i -^t ••• 9n- By applying Lemma 42, 

3<5ir’‘)<3n such that: 



<5i = 



<3n = {qn,---,qn,fi,---,fn) 



Consequently, traces(DT) D traces{T) □ 



4,3 Possible optimizations 
(a) Local choices 

For sake of clarity, the compilation rule treats in a uniform way the choices 
in the initial tester by calling an election service. This election synchronizes 
the whole of the testers. However, there is no reason so that the testers non- 
concerned with the choice cannot evolve independently. This has two conse- 
quences: (1) it is necessary to add a compilation rule to treat the particular 
case of local choices, (2) to avoid blocking problems related to the existence 
of a choice between two r-transitions from a local tester, it should be con- 
sidered that the testers obtained are minimal (within the meaning of r*a 
minimization which eliminates all the r). The additional rule R2 which is a 
simplification of R1 can be written: 



[R2] 



Qi -^T Q2 P-enable{qi) = {i} 



X\sync{q2) 



Qi -^Ti Qi2 ~ ^ Ti VTj G X 
where i = port{a) and X - 



Ti?sync{q2) wT’ ^ V 

> Tj Q 2 i VTjfe g A Qi 

■■ {Tj \ j :/:i A j e p.enable{q 2 )} 



>Tfc q2 



(b) Synthesis of the election service 

The distributed choices can be transformed into local choices by using the 
artifice illustrated in figure 4. The observable traces of the tester remain un- 
changed. The application of rule R2 produces distributed testers running with- 
out the general service of election. More precisely, the election is ensured by 
the circular transfer of control. 



4.4 An example of distribution 

Let us consider a test case whose model is presented in the left part of the 
figure 5. This tester decides to emit interaction a towards the lUT then awaits 
a reaction b or c. If it receives 6, it then awaits c. One wishes to distribute 
this tester on two sites, one having the responsability of interactions a and 6, 
the other of c. 
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Figure 4 Preliminary transformation of the test case leading to an integrated 
election service on a ring of testers where t denotes a r action. 




Figure 5 The initial test case and the result of the synthesis rules. 



The application of the compilation rule R1 produces the two testers intro- 
duced in the figure 5: !a and ?6 are located on tester 1, ?c on tester 2. No- 
tice that the synchronizations ‘T2!a -> Pl?a” and “P2!b -> Pl?b” (through 
the coordination points PI and P2) ensure the sequencing of “!A?B?C” and 
“!A?C”, as well as the use of the election service ensures that the testers make 
the same distributed choice. The figures in Figure 5 and 6 have been obtained 
using the Aldebaran Toolbox [14]. 

We consider now that these testers interact asynchronously and use syn- 
chronously (locally) the election service whose abstracted form is described in 
left side of figure 6 (the primitives elu() and vote() correspond respectively to 
req() and resp() in rule [Rl]). The whole behaviors of the system obtained is 
given by the automaton in the right side of figure 6, which is trace-equivalent 
to the initial centralized tester. 
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Figure 6 The abstract spec, of the election service and the result of the com- 
position, which is trace- equivalent to the initial automaton of figure 5 



5 CONCLUSION 

In this paper, we gave the first results of our works concerning distributed test- 
ing of distributed architecture. We have proposed a method for an automatic 
distribution of a centralized test case. In this kind of test architecture, several 
testers coexist and interact in an asynchronous way to coordinate the testing 
activity. The testers communicate with the lUT, also in an asynchronous way 
via the PC Os. Under the assumption of an underlying service of election, we 
generate a distributed test whose traces reduced to the events on PC Os are 
the same ones as the traces defined by the centralized test case. 

As a distributed testing is typically asynchronous, we have to be carefull 
on the validity of the original test case in an asynchronous environment. In 
fact, a correct test which does not reject conformant implementations in a 
synchronous environment can be biased (i.e. it rejects a conformant imple- 
mentation) when it is carried out in an asynchronous environment. We have 
also defined a characterization of unbiased test cases preserved by the ex- 
istence of an asynchronous environment. We show that it can be computed 
starting from the specifications of the lUT and the tester. Its calculation would 
be an interesting functionality of a tests generation environment. 

As this work is just first steps towards automatic generation of distributed 
tests, several prospects remain open: (1) investigating a way to generate au- 
tomatically the service of election as suggested in Section 4.3, (2) the possible 
concurrencies in distributed testing come from the desynchronization between 
the lUT and the testers. We will try to find a way to extract the potential 
concurrency in the test cases and to use it in the distribution, (3) reduction 
of the number of messages exchanged by the testers for their coordination. 
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Abstract: The main challenges for the tools which derive implementations from formal 

descriptions are to enhance the efficiency and facilitate the integration in 
various implementation contexts. We study in this paper the Estelle based 
implementations. Using the Estelle Development Toolset (EDT), we obtained 
a realistic implementation of a complex transport protocol, XTP 4.0, func- 
tionally comparable with the hand-coded reference implementation. This of- 
fered an experimental ground for a survey concerning the automated imple- 
mentation. Based on runtime measurements, analysis of the Estelle model 
and of the tool's support, we studied the factors influencing the performance 
and the solutions to improve it. 



1. INTRODUCTION 

The use of the formal description techniques (FDT) in the development of 
the telecommunication systems is continuously extending. For protocol de- 
sign, validation and test generation, the advantages of the FDT-based methods 
became obvious. The main challenge remains the complexity of the systems. 

However, the ultimate goal of the protocol development process is to 
obtain the implementation. The automated derivation from the formal specifi- 
cation can ensure that the implementation complies with the specification and 
can greatly reduce the development and maintenance effort. Therefore, the 
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adequate support for implementation, as part of a consistent development 
methodology, can be the cutting edge of an FDT-based tool. Besides the 
conformance, the implementation must match the efficiency requirements of 
the application (runtime properties, code size). Although tool support has 
been available for a long time, the applications are still limited. The main 
cause is the relatively modest efficiency, compared with the current hand- 
coding methods. Furthermore, part of the implementation often cannot be 
obtained automatically: operations not supported by the specification lan- 
guage (e.g., checksum computation, packet encoding and decoding) or not 
detailed in the formal specification ("local matters" in the protocol definition, 
e.g., related to resource management). Also, a non-negligible effort is often 
necessary for integrating the implementation in a particular context (e.g., to 
interface it with other components, implemented by hand). 

The aim of our study was to investigate these difficulties, by obtaining a 
realistic implementation from an Estelle specification, using EDT (Estelle 
Development Toolset) [11]. The Xpress Transport Protocol (XTP) 4.0 was an 
ideal example [15]. XTP 4.0 is a challenge for the implementer: it covers the 
functionality of existing protocols (TCP, UDP), includes new features needed 
by modem applications (e.g., multicast) and can accommodate various 
communication paradigms, media requirements and network properties. We 
already had a (virtually) complete Estelle specification, verified by simulation 
[3]. A hand-coded C++ implementation of the protocol, SandiaXTP, was 
available for comparison [14]. It mns on UNIX machines, in user space, on 
top of IP or UDP, and provides an application programming interface (API) 
adapted to the XTP extended functionality. 

We used EDT to implement XTP 4.0 from the Estelle specification, for 
the same environment. The implementation, called E-XTP, provides full XTP 
functionality to real UNIX applications, can inter-operate with SandiaXTP 
and has a similar API (E-XTP is an enhanced version of the implementation 
presented in [4]). Section 2 introduces the EDT implementation model and 
section 3 contains an overview of the resulted XTP implementation. 

The derivation of E-XTP offered a valuable experimental ground for our 
survey concerning the improvement of the Estelle based automated 
implementation. We made a joint analysis of the runtime measurements, of the 
Estelle model and of the tool's runtime environment, to identify the factors 
affecting the efficiency and to evaluate their influence. We studied pragmatic 
improvement solutions, including the integration of efficient hand-coding 
techniques, implementation aware specification styles, optimisation of the 
tool's libraries. The results are summarised in section 4, structured in two 
parts: communication issues and system management. Part of the solutions 
have been experimented during the derivation of the XTP implementation, 
others are currently being studied for future integration in EDT. Conclusions 
and further work are presented in section 5. 
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2. EDT AUTOMATED IMPLEMENTATION 

2.1 The C code generation 

EDT maps an Estelle system module instance (SystemProcess or 
SySTEMActiyity) to a process of the target operating system and inple- 
ments the children modules as procedures. It generates a separate program for 
each body of an Estelle system module in the specification [12], 

First, the Universal Generator tool (Ug) splits the original specification, 
e.g., spec.stl, in several separate specifications, one for each system module 
body, e.g., mb_k.stl. Each specification mb_k.stl contains a system module 
from spec.stl, embedded (as unique child) in a new Estelle system module, 
automatically generated by Ug. The role of the embedding module is to 
transfer messages between the original system module and the environment. 

Next, for each specification mb_k.stl, the Estelle to C compiler (Ec) gen- 
erates a C program and a make file. The C code generated by Ec is independ- 
ent of the target implementation platform. Moreover, the same C code is used 
to obtain the simulator program, with the EDT simulation library, and the im- 
plementation, with the EDT implementation library. One can thus be confi- 
dent that the implementation reproduces the behaviour verified by simulation. 

We can continue either by immediately producing a prototype of the dis- 
tributed system, or by further refinement, to obtain a final implementation. 
For the first case, EDT can automatically distribute the system's components 
on user selected hosts. The set of Estelle system module instances and com- 
munication links from spec.stl is mapped on a set of processes communicating 
via TCP/IP. Alternatively, we can adapt the implementation to a particular 
context and improve its efficiency, by customising the primitives in the tool's 
libraries. The XTP implementation was obtained using the second approach. 

2.2 The interface with the environment 

The embedding module added by Ug is the interface between the contained 
module and the environment. Each external interaction point of the original 
module is attached to an internal interaction point of the embedding module. 
The transitions of the added module perform the adaptation between the 
Estelle message based communication and any inter-process communication 
mechanisms provided by the target operating system (e.g., sockets, message 
queues, signals, etc.). For this purpose, the EDT implementation library offers 
four generic primitives, mxinit, mxwhen, mxoutput and nvcsend, used by Ug 
as shown in this example: 

INITIALIZE 

BEGIN 

mxinit; { IPC mechanism(s) initialization j 

END; 
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TRANS {Outgoing interactions processing: for each interaction point and type} 
WHEN s _p_sap.Data_req 
BEGIN 

mxsendi 1, 0); ( send Datajreq using an IPC mechanism } 

END; { s __p_sap identifier =7, Datajreq interaction identifier =0 } 

/ ... and the transitions for the other outgoing interactions } 

TRANS (Incoming interactions processing (2 interaction points in this example)} 
ANY X : 0 ..1 { for X = any of the interaction points } 

PROVIDED mxwhen(x) { a message is received for interaction point x } 

BEGIN 

mxoutput(x); { output the corresponding Estelle interaction 

END; { to the interaction point x } 

This approach avoids any modification of the original Estelle specification 
and offers maximum flexibility for implementing the interface. The user can 
choose interface functions from the tool's library or develop customised ver- 
sions. The restriction is that the IPC mechanisms used for input events must 
match those known by the kernel function which detects the events, described 
in the following. 

2.3 The dispatcher function 

The dispatcher function, provided by the EDT library, is the core of the 
process which implements an Estelle system module. It contains an infinite 
loop, in which the process waits for an event, selects the fireable transitions 
(system management phase) and then fires them (execution phase). 

The process blocks waiting for the arrival of incoming messages from the 
environment or the expiration of running timers (corresponding to enabled 
delayed transitions). The detection of an event wakes up the process, which 
starts to execute the loop. A timer management function updates the list of 
running timers and marks the delayed transitions which become fireable. 
Then, a set of transitions is selected and fired. The set may contain several 
transitions, for the System-Process attribute, and a single transition, for the 
SystemAcuvity attribute 

The process continues to run as long as fireable transitions exist, i.e., until 
it achieves the treatment of the event which woke it up and those which 
occurred in the mean time. Eventually, the process blocks waiting for another 
input or time-out event. During a run, the process fetches (at most) one 
incoming message from each input port and achieves their treatment before 
letting other messages in. Therefore, an implicit flow control on incoming 
messages is provided. This is a useful property for an implementation, which 
is not guaranteed by the Estelle semantics, due to the asynchronous communi- 
cation model with unlimited queues. As a side effect, the parallelism between 
the Estelle sub-modules is reduced. 
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3. XTP AUTOMATIC IMPLEMENTATION 

3.1 Overview of the specification and the implementation 

The goal of the XTP design was to obtain a connection oriented transport 
protocol with extended functionality and flexible configuration, adaptable to 
the fast evolution of the networks and the applications (high speed networks, 
distributed applications with transactional, multipeer and multimedia commu- 
nications). The protocol kernel is a toolkit of mechanisms with orthogonal 
functionality. They can be independently enabled, to obtain combinations 
permitting various communication paradigms. The protocol definition [15, 2] 
is not accompanied by a transport service definition. It only suggests how to 
use the toolkit to obtain a basic set of service types: unicast and multicast 
connection oriented or datagram service, unicast transaction service, etc. 

We adopted an implementation context similar to that of SandiaXTP [14], 
the reference XTP 4.0 implementation, hand-coded in C-i-i-: UNIX environ- 
ment, UDP/IP sockets at the data delivery service interface, UNIX domain 
sockets and XTP-specific application programming library at the transport 
service interface. Figure 1 shows E-XTP and SandiaXTP running on hosts 
connected to Internet. Figure 2 is a closer look at a host running E-XTP, with 
the XTP process providing connections for 2 transport service user processes. 

The block XTP corresponds to the original XTP Estelle specification. The 
block Xtpi is the embedding Estelle module produced by Ug. The Estelle 
module XTP describes an XTP entity. It only performs management tasks. For 
each communication, an XTP entity keeps a state record, called a context. A 
communication (any type of service) requires an association of contexts from 
the participating XTP entities. A CONTEXT module is the state machine which 
controls the activity at one association endpoint. The CONTEXT instances are 
dynamically created by Xtp, for the duration of an association. The module 
Packet_MNGM is the interface with the underlying connectionless network 
service. It submits outgoing packets to the network layer and decodes 
incoming packets and routes them to the destination CONTEXT instances. 

The Estelle specification covers almost completely the XTP features pre- 
sented in the informal specification. The mechanism for allocating CONTEXT 
instances to users, a "local matter", was not specified in Estelle (it was left to 
the C primitives of the interface). An interaction of the transport service 
interface just carries the index of the source or destination CONTEXT instance. 
The specification remained of moderate size (8000 lines), compared with the 
rich XTP functionality, by exploiting the XTP design principles (mainly for 
multicast) and by using a parametric transport service. The Estelle support 
for complex algorithms was essential for covering the XTP functionality, e.g., 
for managing the receiver group state in a multicast transmitter. 

The core of the implementation consists of the C code generated by the 
Estelle compiler from Xtpi (20000 lines) and the EDT library functions 
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which implement the Estelle model (inter-module communication, transition 
selection, etc.). The size of the executable code is 210 kilobytes, similar to 
that of SandiaXTP 1.5. 




Figure L Hosts running E-XTP and SandiaXTP (TS = transport service). 




Figure 2. E-XTP structure and the interactions with the user processes. 
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UIF-TS is the interface of the user process for access to the transport 
service. It provides an API library [5] similar to that of SandiaXTP. UIF-TS 
is a state machine driven by messages received from E-XTP and by function 
calls made by the application program. Two communication mechanisms are 
involved: message transfer, via a UNIX domain datagram socket (UX-DSO), 
and shared memory, for sent and received data units. UIF-TS takes all the 
data types necessary for communicating with E-XTP from two C header files 
generated by the Estelle compiler from the specification. 

XIF-TS is the interface of the XTP process with the transport service user 
processes. It consists of four C primitives, which are customised versions, for 
the XTP transport service interface, of the four EDT generic interface primi- 
tives (section 2.2). XIF-TS provides the adaptation between the Estelle inter- 
module communication mechanism and the UNIX domain datagram socket 
(UX-DSO), used for exchanging messages with the user processes. It is also 
responsible for the allocation of CONTEXT instances to users and for routing 
the messages between the user processes and the CONTEXT instances. 

XIF-DS is the interface of the XTP process with the underlying data deliv- 
ery service. It consists of four C primitives, customised versions for the 
UDP/IP interface, of the four EDT generic interface primitives. XIF-DS pro- 
vides the adaptation between the Estelle inter-module communication mecha- 
nism and the UDP datagram socket (UDP/IP-DSO). It also performs the ad- 
aptation between the XTP packets representation in the Estelle specification 
and the real XTP packet formats, as well as the checksum computation. 

UDT/UDR-SHM are shared memory buffers of the UIF-TS interface, used 
for data transmission and data reception, respectively. They are created by the 
user process and shared with the XTP process. These buffers permit the data 
transfer between the user process and an XTP context with a single data copy. 
XDT/XDR-BUF are collections of data buffers used by the XIF-DS interface. 
They store the data segments of the outgoing XTP packets and the received 
XTP packets, respectively. The transfer of the XTP data packets between the 
XTP contexts and the data delivery service requires a single data copy. 

A Context instance contains the pair of buffers CDT/CDR-FIFO. CDT 
stores the transmitted data until acknowledgement. CDR stores the received 
data until the recovery of the lost segments and the delivery to the user. They 
existed in the Estelle specification, but the Pascal procedures for managing 
them are replaced by C primitives, aware of the UIF-TS and XIF-DS buffers. 

3.2 E-XTP versus SandiaXTP 

E-XTP and SandiaXTP provide similar XTP functionality, with similar 
API functions and can inter-operate. Both are user space implementations for 
UNIX environment and use sockets and shared memory for inter-process 
communication. However, there are important differences in the state machine 
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design and some protocol functions are performed using different policies. 

Figure 3 shows throughput measurement results for SandiaXTP and E- 
XTP. They are made for a one-way data transfer, with Sparc stations Ultra 1, 
running Solaris 2.5, on 10 Mbit/s Ethernet. The following protocol settings 
are used: flow control, error control and checksum enabled; rate control 
disabled; no segmentation, acknowledgement at end of window. For these 
typical settings, the two implementations offer quite similar throughput 
values. E-XTP seems better tuned for multicast communications. Running in 
user space is a major handicap for both of them. As shown in the next section, 
about 50% of the processing time per data unit goes to system calls. 
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Figure 3. Throughput of E-XTP and SandiaXTP (user buffer to user buffer) as 
a function of the data unit size. The window size is 24 data units. 

4. THE FACTORS AFFECTING THE EFFICIENCY 

4.1 Communication mechanisms 

Data and packets manipulation is the most obvious cause of overhead in a 
layered protocol architecture [6]. The various optimisation techniques used in 
hand-coded implementations [13] are based on the following principles: 

- Avoid moving the data units by storing them in shared memory buffers 
and passing pointers to buffers between the communicating entities. 

- Manage the variable size of the data units (insertion and removal of layer 
specific headers) without copying them, using either off-setting or scatter- 
gather. In the former case, a data unit is stored in contiguous memory, in a 
buffer accommodating the maximum data unit size, at a variable offset. In 
the latter case, the components of a data unit are kept in individual buffers 
and a descriptor indicates the number of buffers and their addresses. 

- Integrate data processing (checksum computation, encryption, etc.) for 
multiple layers, to reduce the number of memory cycles [1]. 

- Anticipate the contents of the packet's or message's components, to 
minimise processing when sending them. 





379 



However, the integration of these optimisations in the automatic code gen- 
erators is complicated by the FDT constraints and the difficulty to determine 
when and what some particular technique is useful and can be safely applied. 

For a system modelled in Estelle, the communication consists (mainly) of 
asynchronous message exchange. The mapping of module instances to proc- 
esses or procedures and the scheduling algorithm affect the implementation of 
the communication mechanisms. We refer in the following to the EDT model 
(atypical solution). Two kinds of communication can be identified; 

- external communications, with the environment of the process; 

- internal communications, with (sub)modules within the process. 

For the first category, the implementation must rely on the inter-process 
communication (IPC) mechanisms offered by the target operating system. The 
tool must provide interface libraries for various operating systems and IPC 
mechanisms or/and enough flexibility to allow the user make the necessary 
adaptations. The latency of the IPC mechanisms is often the main cause of 
inefficiency. Shared memory and scatter-gather, if available and exploited by 
the tool's libraries, can avoid or minimise the data copying overhead. 

The efficiency of the internal communications is mainly affected by the 
FDT restrictions. A general (always safe) solution cannot avoid copying the 
message parameters. For the implementations obtained with EDT, the transfer 
of an interaction implies a single copy of the parameters. First, an interaction 
buffer is allocated from a common pool and the parameters' values are copied 
to it. Next, the buffer's address is appended to the destination queue. The 
interaction's parameters are directly accessible to the receiving transition. The 
buffer is released when the execution of the receiving transition terminates. 

However, the modules often just forward received information, possibly 
adding or removing some parts. This is due to the information transfer princi- 
ples in layered protocol architectures and to message routing within the proto- 
col entities. In such cases, the copy operation is redundant and very harmful 
to the implementation's performance (e.g., for a non-trivial protocol entity 
architecture, the packets are repeatedly copied). Queue management and mes- 
sage routing have a relatively more modest contribution. 

Here is a simple example of packet transmission: 

VAR p: pdujtype; 

BEGIN 

build _pdu(p); 

OUTPUT ip_out.pdu(p); 

END; 

First, the packet is built in a local variable. Then, the Output statement is 
executed, allocates a buffer and copies the variable. The packet's fields 
(control, data segment) are copied twice, first to the variable, next to the 
interaction buffer. Obviously, the operations should be done in the reverse 
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order: one should first allocate the buffer, then use it to build the packet. For 
instance, the local variable p could be mapped to an interaction buffer. This 
requires a code generator able to detect that the variable is used as a 
parameter in a single OUTPUT statement and it is not modified afterwards. 

The remark also inspires a different specification style. It is often possible 
to have most of the contents of the packet already prepared, as part of the 
local state. One can define the components of the packet as parameters of the 
interaction and let the OUTPUT statement assemble them (which is also more 
favourable for optimisations using scatter-gather or off-setting). Here is 
another example, a data transmission using the suggested solutions: 

WHEN ip_in.data_req(sdu) 

BEGIN 

putjbuffsdu); { append the data to the transmission buffer ) 

IF can_send THEN BEGIN { flow control permits transmission } 
crtjieader.sequence ;= (crtjieader.sequence + 1) mod MaxSeq; 
OUTPUT ipjout.dt _j>du(crt_header, sdu); 

END; { else: send when a received CNTL packet advances the window } 
END; 

With this specification style, the transfer of the interaction causes only one 
copy of the packet's fields. The example also introduces another element in- 
volved in data manipulation: the transmission buffer, responsible for storing 
the data until the transfer is acknowledged. The copy operations to/from this 
buffer can be avoided if the data are stored in shared memory buffers and 
both the message transfer management and the transmission buffer manage- 
ment are aware of this. The operations depend on the protocol rules, unknown 
to the code generator. However, there are solutions which do not require spe- 
cial code generator capabilities and satisfy the generality required from a 
specification. We can make the sdu type a buffer descriptor (which can be 
copied without harm) and use C primitives for protocol buffer management. 

In conclusion, several strategies can be used for integrating optimised data 
manipulation techniques in the automatic implementations. 

One approach relies on the code generator for detecting particular situa- 
tions when it can use an optimisation, instead of the general (always safe) 
method. Such a solution is proposed in [9]. Alternatively, the code generator 
could be guided with annotations inserted in the specification, indicating 
explicitly the context of the desired application of some optimisation tech- 
nique. We are currently studying this solution, which seems more flexible and 
realistic, as it relies on the user's knowledge of the protocol's functionality. 

Another approach uses C primitives for buffer management provided by 
the tool's library. It is the only solution which can address particular features 
of the implemented system and of the implementation context. It can comple- 
ment the previous approaches, limited to general message transfer issues. 
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The latter strategy was used for E-XTP. One goal was to optimise the data 
path between the user buffer and the UDP/IP interface, with external and in- 
ternal communications and send/receive buffer management. Another goal 
was to treat packet manipulation issues: encoding, decoding, checksum com- 
putation. The FDT data types and operators do not allow the use of real 
packet formats in the specification. Hence, the protocol machine works with 
an internal packet format (also "readable" by the simulator, for validation). 
The adaptation between the internal format and the real XTP format and the 
checksum computation are made by the primitives of the UDP/IP interface. 

However, these problems mainly concern the control information in the 
packets. For data segments, the size and the order are the only issues which 
interest the protocol state machine. Therefore, it only knows a descriptor indi- 
cating the size of the data unit and the buffer which holds it. A transmitted 
data segment joins the header only when moved to UDP/IP and a received 
packet is split as soon as it is retrieved from UDP/IP (using scatter-gather). 
All the user data manipulations are done by a set of C primitives, responsible 
for moving the required amount of data between the CDT/CDR ring buffers in 
the Context module and the UDT/UDR user buffers or the XDT/XDR buff- 
ers in the XIF-DS interface (figure 2). Two copy operations are implied by 
this scheme (solutions with less copy operations were difficult to apply to the 
existing specification, requiring the redesign of the data streams manage- 
ment). The buffer management primitives used in the CONTEXT module coop- 
erate with the interface primitives in the Xtpi module. Hence, efficient solu- 
tions offered by the implementation context could be used: shared memory 
buffers at the upper interface and scatter-gather at the UDP/IP interface. 
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Figure 4. Contribution of the interfaces to the total processing time per data unit, for the 
XTP implementation (1024 bytes data units, Sparc station Ultra 1). 

The experiments with E-XTP indicate a 300% increase of the user-to-user 
throughput, just by avoiding the copy operations for user data [4]. Figure 4 
points out another major cause of throughput limitation: the latency of the 
socket interface. The values include three system calls: an exchange of mes- 
sages with the user process, via the UNIX domain datagram socket, and the 
transmission or the reception of the XTP data packet, via the UDP socket. 

E-XTP uses a connectionless underlying service. The lower interface just 
maps Estelle interactions to UDP/IP socket datagrams. This can be done by 
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primitives from a general purpose library, which call user defined functions 
for application specific message processing. In general, the mapping can be 
much more complex, e.g., for a connection oriented service accessible through 
an API library like TCP sockets or TLI. The flexibility of the EDT approach 
to external communications can be an important advantage in such cases. 

4.2 System management overhead 

An Estelle specification describes an hierarchically structured collection of 
module instances. The system modules occupy the top of the hierarchy. They 
run independently and synchronise with each other only by message exchange. 
Within a system module, further synchronisation rules are imposed: priority 
of a parent module over the children modules and, depending on the module 
attributes, either parallel synchronous or asynchronous interleaving execution. 

According to the operational semantics, a system module performs cycli- 
cally a management phase, to identify the fireable transitions, followed by a 
transition execution phase. This is the usual approach adopted by the Estelle- 
based implementation tools. The transition selection algorithm is complex and 
can cause an excessive overhead. Various solutions to reduce this overhead 
have been investigated [7, 8]: optimisation of the algorithm defined by the 
operational semantics, structural transformation of the specifications, identifi- 
cation of favourable specification styles, different scheduling policies, etc. 

As pointed out in [13], two main classes of models are used in hand-coded 
implementations: the server model and the activity thread model. With the 
server model, each system component processes events in an endless loop. 
The set of components communicate asynchronously and a scheduler offers to 
each one a fair chance to run. With the activity thread model, the components 
are implemented by procedures and communicate synchronously. The output 
of a message from a component is implemented by a call to the procedure 
which treats that message in the destination component. The system treats one 
event at a time, as a sequence of procedure calls (i.e., the "activity thread"). 

The existing automatic implementation tools, including EDT, use the 
server model, which better matches the Estelle and SDL semantics. The ac- 
tivity thread model can provide a considerable performance improvement, 
when applicable. However, there are major contradictions between the Estelle 
model and the activity thread implementation model. Hence, excessive restric- 
tions for the Estelle specifications are needed to permit its use [10]. 

The current EDT implementation kernel uses a (relatively) optimised tran- 
sition selection algorithm. It performs a single-pass search in the tree of 
module instances. For each instance, it looks for fireable transitions using 
table-based decodification (input/state table) followed by programmed selec- 
tion (checking of provided clauses, interaction point identity, priorities). The 
algorithm is fully compliant with the Estelle operational semantics and does 
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not impose any restrictions concerning the Estelle language features. 

One of our goals was to evaluate the influence of the system management 
overhead on the implementation's performance and its dependence on the 
Estelle model features and specification styles. The analysis was based on 
measurements made by probes inserted in the dispatcher loop (section 2.3). 
The time-stamps provided by these probes allow the calculation of pairs of 
values representing the execution duration for a transition and the duration of 
the preceding system management phase. The histograms in figure 5 show re- 
sults of the measurements for E-XTP (average values). They were made on a 
Sparc station Ultra 1, for the following settings: SystemActivity attribute, 
one way transfer with 1024 bytes data units, error control, flow control and 
checksum enabled, no segmentation, one acknowledgement packet for 10 data 
packets. Figure 6 shows the overall contribution of the management phase to 
the processing time per data unit, done within the Xtp module (computed 
from the collected samples, taking into account the relative firing rate). 
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Figure 5. Management and transition execution duration for the data transfer, 
in a Context module instance. 
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Figure 6. Contribution of the system management duration 
to the processing time per data unit, in the Xtp module. 

The joint analysis of various measurements, of the transition selection 
algorithm and of the specification, summarised in the following, points out the 
main causes of this relatively important overhead, as well as some solutions. 

Due to the synchronisation constraints and the necessity to provide a cer- 
tain fairness, the scheduler maintains a relatively complicated, tree-like, list of 
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module instances, reflecting the hierarchy. A selection implies a traversal of 
this list, often partial, but always starting from the root. For each instance, the 
fast, table-driven decoding, based on main state and input (if any), offers in 
general two sets of transitions, not just a single transition. One set contains 
the input transitions for the received interaction(s). The other set contains 
spontaneous transitions (no input), including delayed transitions, used to 
model timers. A slower, programmed selection must be used to choose a tran- 
sition from these sets, by checking the PROVDDED clause, the priority and (for 
input transitions only) the interaction point. 

The influence of the synchronisation rules on the selection duration de- 
pends on the depth of the hierarchy and the module attributes. An adequate 
choice of the attributes can reduce the overhead per executed transition. The 
SystemProcess or Process attributes require the visiting of all the children 
instances (when the parent has no fireable transition), but all the offered tran- 
sitions are executed before the next management phase. The System- 
Actiyity or Activity attributes allow the termination of the search at the 
first module instance offering a transition (with some fairness rule). For a 
high degree of concurrency between children instances, the former attributes 
are the preferred choice, otherwise, the latter. 

The spontaneous transitions, mainly the delayed ones, are a major cause of 
overhead. They should be avoided, but two Estelle features demand their use. 

The first one is the constraint to indicate the next main state in the transi- 
tion header, before processing the received interaction. If the next state cannot 
be determined by a simple condition, tested in a PROVIDED clause, a sponta- 
neous transition must be added just to change the main state. This artificial 
solution can be avoided by relying on variables and the provided clause, 
instead of the STATE declaration and the clauses FROM and TO. However, in 
this case, the table-driven decodification works on input only and a larger set 
of transitions remains for programmed selection. The possibility to change the 
state in the transition’s body and to use output interactions in procedures 
would reduce to a large extent the need to use spontaneous transitions. 

The second source of spontaneous transitions is timer modelling, using 
delayed transitions. A timer is associated to each delayed transition and runs 
while the transition is enabled. The enabling of a delayed transition corre- 
sponds to a "start" timer command and the disabling to a "stop" timer com- 
mand. The transition is fired when the timer expires. The main state and/or a 
provided clause can be used to control the timer's activity. The inefficiency is 
due to the fact that the start/stop commands are implicit and the scheduler 
must check systematically the conditions of the delayed transitions to detect if 
a timer must be started or, conversely, if a running timer must be stopped. It 
is often necessary to restart a timer before expiring. Such a "restart" timer 
command, can be obtained by combining a "stop" and a "start". However, two 
computation steps are necessary: the first one to disable the delayed transition. 
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the second one to re-enable it. Another spontaneous transition must be added 
for the second step (e.g., the transition "start wtimer", in figure 5). 

The presence of multiple interaction points, individual queues and transi- 
tion priorities complicates the selection of the input transitions. First, there is 
a list of queues to be visited. Next, all the queues must be visited, even after 
finding an interaction, to check the priorities. Therefore, the preferable speci- 
fication style is to indicate common queue as default and use individual 
queues only when really necessary. A common queue is especially important 
for multiplexer modules (e.g., PaCKET_MNGM in the XTP specification) and 
usually there is no inconvenience. This kind of functionality is present very 
often in the systems and requires arrays of interaction points and transitions 
parameterised using the Any clause. The selection algorithm and the code 
generator must treat these features with special care. 

The excessive overhead of the outlined algorithm is due to the complex 
search of the transitions to fire. It is a general method, able to deal with the 
worst case. The solution we are studying is to replace the search by an event 
based management of a list of instances scheduled for (transition selection 
and) execution. If there are no spontaneous transitions, the list can be organ- 
ised based on transferred messages: once a message is output, the receiving 
instance is inserted in the list. The solution can be extended for spontaneous 
transitions, if the Provded clauses do not contain primitives or exported 
variables. In such a case, they can only be enabled by the execution of another 
transition of the same instance. The spontaneous transitions are checked only 
in this situation. If anyone is fireable, the instance qualifies for the scheduling 
list. It seems possible to obtain a considerable improvement for limited 
restrictions, acceptable by many applications. 

5. CONCLUSIONS 

The derivation of E-XTP from the XTP 4.0 Estelle specification, allowed 
us to asses the current EDT support for automatic implementation. E-XTP is 
functionally comparable with the hand-coded implementation SandiaXTP and 
inter-operates with it. They have similar, but relatively moderate performance. 

The automatic implementation methods can match the requirements of the 
modem high speed network environment only if they integrate the highly effi- 
cient techniques already used in hand-coded implementations [9, 13]. Of main 
interest are the solutions used for data and packets manipulation and for 
mapping the system's components (e.g., entities in a layered protocol ar- 
chitecture) to processes or threads of the target implementation environment. 

We experimented the optimisation of the data stream implementation using 
libraries of primitives which integrate the internal and external communica- 
tions and the protocol buffer management. The approach is pragmatic and 
flexible. The libraries can be reused for applications having the same imple- 
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mentation context. Further benefits can be obtained by adding automatic code 
generator support for general message transfer optimisation. 

Our analysis pointed out the Estelle features responsible for the excessive 
system management overhead. It also showed that the scheduling algorithm 
can be substantially improved, for widely acceptable constraints. The effi- 
ciency can approach that of the activity threads, without the excessive restric- 
tions imposed by the strict application of this model [10]. 

The solutions used in the specification must take into account implemen- 
tation issues and must be correlated with the support offered by the tool. A 
good basis for the implementation could be obtained without loss of the speci- 
fication's generality, using just an adequate specification style. The adaptation 
in the implementation phase is expensive, harmful and should be avoided. 
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Abstract: In this paper a co-design methodology based on multiformalism modelling is 

presented. It defines a platform that integrates different notations and, the 
necessary mechanisms to handle different in nature models in a coherent way. 
The supported formalisms cover a wide area of application domains, allowing 
the designer to select the notations that are mostly appropriate for his/her 
application. The proposed co-design development cycle provides a full blown 
path from system specification to a virtual prototype of the system under 
construction. The methodology has been applied for the design and 
implementation of a MAC layer protocol, named MASCARA, for providing 
ATM QoS over wireless connections. 



1. INTRODUCTION 

During the last years, a new generation of design methods for embedded systems, 
referred to as co-design [8, 10, 12, 13, 14, 15, 17, 18], has emerged and matured. 
These methods are able to handle mixed hardware/software systems starting from 
behavioural-level down to implementation. They are based on co-design tools that 
are capable of providing concurrent design of the different parts of heterogeneous 
distributed systems, automation of H/W-S/W partitioning and automation during the 
integration steps at the lower levels of the development cycle. 

In the next paragraphs we present a co-design development cycle that supports 
different specification formalisms. The goal is to propose a methodology that 
embraces a wide range of application domains [6] under a consistent co-design 
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framework that leads to a virtual prototype of the final system. The proposed 
methodology framework is exhibited through the design of MASCARA protocol, a 
MAC layer protocol for wireless ATM networks. 



2. CO-DESIGN USING MULTIPLE FORMALISMS FOR 
SYSTEM DEVELOPMENT 

The increase of complexity in embedded systems and the demand for virtual 
prototypes as early as possible in the design cycle, are putting strict requirements on 
methodologies and the tools supporting them. The co-design approach proposed in 
this paper aims at building a coherent couple of methodology-toolset for the entire 
design cycle of embedded systems. Particular emphasis is given on the phases of 
system-level co-modelling, co-simulation , partitioning and co-targeting. 

Co-modelling aims at formalising the specifications of an embedded system. Such 
specifications usually include several evolving models described by means of 
different notations. Co-simulation can be used at this stage, before partitioning, to 
conduct an early validation of the specifications. Co-simulation, as it says, involves 
simulation of at least two different models that interact among each other e.g. 
exchange data dynamically. Then comes partitioning to decide which parts of the 
system are going to be implemented in SAV and which parts in HAV. Partitioning 
takes into account the target platform (e.g. processors, distributed architecture etc.) 
to assign each system part. Co-simulation can also be used at this stage to estimate 
the validity of the choices. Finally, once the partitioning is agreed, targeting takes 
place. It involves SAV code generation, HA^ synthesis, realisation of interfaces 
between HAV and SAV modules, and implementation of the whole system into the 
target platform. 

The proposed methodology-toolset materialises a design environment for hybrid 
(continuous and discrete) HAV - SAV embedded systems. It supports a global design 
flow, based on multi-formalism modelling and executable prototypes to validate the 
system design. The toolset accompanying the proposed methodology has been built 
from existing products and prototypes, which have been adapted and extended for 
the needs of industrial end-users. Interfaces have also been developed for connecting 
external tools such as VHDL tools for HAV design. The co-design flow detailed in 
Figure 1 outlines the methodological stages involved in the design of embedded 
systems. 

From the formalism point of view. Figure 2 depicts how the associated supporting 
tools are combined in the context of the proposed approach. The circles depict the 
co-modelling and co-simulation modules that have been developed for the need of 
our methodology. They implement MATRIXx-SCADE co-modelling , SDL-SDL 
co-execution, MATRIXx-Statechart co-simulation, SDL-MATRIXx-Statechart co- 
simulation and C-VHDL co-simulation [6]. Therefore multi-formalism co- 
simulation is possible both at the specification level and at the implementation level. 
Two more arrows have been drawn to indicate improvements dealing with software 
distribution using SEA and VHDL generation from SDL using COSMOS. The latter 
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platforms are used in the partitioning phase: COSMOS produces C for SAV parts 
and VHDL for HAV parts, while SEA generates C from Statechart and MATRIXx 
models for distribution on a given HAV platform. Code generation and targeting is 
realised by taking into account the constraints attached to embedded systems such as 
e.g. communication efficiency and memory limitations. 




Figure 1. HAV- SAV co-design using multiple formalisms for embedded system design 



Regarding the tools that match with the various phases of the proposed 
methodology, the following could be mentioned. For co-modelling, the user can 
employ four notations: Lustre [6], SDL [1, 3, 6], Statecharts [7, 6] and MATRDCx 
[6] diagrams. Each of these notations is supported by a corresponding tool and the 
proposed toolset provides for their efficient interconnection. With respect to 
partitioning, the user can rely either on the COSMOS [4, 11, 17] approach (covering 
SDL, Statechart, C and VHDL formalisms), or on the SEA [5] approach (involving 
MATRIXx, Statechart and C notations) for software distribution on hardware. As 
already mentioned, co-simulation is possible both at the specification and at the 
implementation levels, for the purpose of model validation and partitioning 
assessment respectively. Application targeting is generally covered by the 
partitioning tools and also by the CASE/CAD tools. 
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3. SDL-STATECHARTS CO-MODELLING PRIMITIVES 

The effectiveness of the proposed approach has been tested over a number of 
different application domains including automotive, aerospace and 
telecommunications. Since the primary goal of this paper is to present the adaptation 
of the proposed methodology/toolset to embedded telecommunication systems, we 
will restrict our analysis to the tools usually involved in such systems. The following 
sections introduce the idea of developing telecommunication systems using SDL and 
Statecharts as complementary formalisms for system specifications. A set of 
transformation rules between Statechart and SDL is also presented, and proposes the 
required extensions to couple the two languages. 




Figure 2. Tool coupling for multiformalism system specification 



3.1.Statechart notation vs. SDL notation 

The Statechart notation is an extension of the Finite State Machine notation. The 
primary objective of this modelling technique is to describe the system behaviour by 
means of a hierarchy of state diagrams. Concepts such as state refinement and 
concurrent activities are supported, allowing to represent a system behaviour at 
different levels of abstraction. The Statechart model is now popular and is present in 
well-know systems and software engineering techniques such as UML [2] or ROOM 
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[16]. It is used to model real-time systems that are centralised (i.e. without 
communication and synchronisation) and have a static architecture (i.e. no dynamic 
task creation). 

The SDL notation has been defined to model and develop distributed real-time 
systems. The concept of dynamic objects that can be created/suppressed, is 
supported, so the system at run-time may behave as a dynamic network of 
communicating processes. For this purpose, SDL supports the necessary 
mechanisms for communication. The simulation and dynamic checking of SDL 
models are possible because of the underlying formal semantics of the language. The 
production of executable code is also possible, to be compared for example with the 
Statechart technique where C/C++ code has to be entered to describe the actions in 
the transitions. SDL is a graphical language as Statechart is, but does not include 
state abstraction facilities, and transition diagrams are purely flat diagrams, 
hierarchical states are not possible, neither entry and exit actions. 

3.2. Complementary features between Statechart and SDL 

From the conceptual point of view, the Statechart and SDL notations seem rather 
complementary than in competition. Statechart provides facilities for model 
abstraction, whereas SDL provides a complete graphical language to describe the 
dynamic behaviour at the lowest level. Statechart can be used early in the system 
development, to sketch a first description of the behaviour that can be given to non- 
expert users. Then this model can be refined with SDL at the detailed design stage, 
to provide a complete behavioural description. The latter can be transmitted to the 
development engineers for production, and to the validation teams for checking the 
conformance to the specification constraints. 

Therefore a solution that integrates both notations to take advantage of their 
respective facilities is welcome. If most of the Statechart concepts are interesting for 
introduction in SDL, the concept of concurrent activity seems not complementary at 
all with SDL. The SDL designer usually describes the concurrent objects - that exist 
at run-time - by processes. Internal concurrency seems unnecessary for these 
objects; if parallel actions must be described, the right way would be to refine the 
object in two separate processes which can run in parallel. Besides it must be noted 
that internal concurrency is forbidden or not recommended in most Statechart 
techniques such as UML or ROOM. At last, it is worth to remind that internal 
concurrency is the unique way to structure the system in the original Statechart 
notation. 

3.3. An approach to combine Statechart and SDL 
notations 

The approach should take as basis the complementary nature of Statechart and SDL, 
as discussed above. The natural way of working is to use Statechart first for 
conceptual modelling. Basically, a Statechart model is a hierarchy of state diagrams. 
The next step is to transform them into SDL constructs and to derive an architectural 
model. Finally the latter will be completed in SDL in order to obtain a detailed 
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design model that can be simulated. It must be noted that those considerations on the 
use of the concepts are independent of the support provided by the tools. 

Therefore the main task is at language level to identify which Statechart constructs 
must be included in SDL, and how to transform them in standard SDL. For the ease 
of integration, assume a notation for Statechart that is a superset of UML, without 
preventing the use of the basic Statechart. 



3.4.Mapping between Statechart and SDL 

Table 1 makes the correspondence between Statechart constructs and SDL standard 
constructs. The basic primitives of mapping SDL constructs to Statecharts and vice 
versa are explained as follows: 



Table 1. Correspondence between Statechart and SDL constmcts 



Statechart construct 


Corresponding SDL construct 


State name 


State name 


Entry action 


No direct correspondence 


Exit action 


No direct correspondence 


Activity 


No direct correspondence 


Initial state 


Start 


End state 


Stop 


Macro-state 


No direct support 


Internal concurrency 


Not supported within the same process; 
basically supported between processes 


Transition 


Transition 


Event with parameters 


Signal with parameters 


Provided (condition) 


Enabling (condition) 


Action 


SDL transition body 


Output 


Output 


Internal transition 


Usual transition 


Delay 


Timer (set, reset and expiration) 



• Activities : Activities i.e. sequential processing without the triggering of events, 
are not supported in SDL finite state machines. In SDL, actions are only 
performed on transitions. However it can be shown that activities can be easily 
modelled in the SDL notation extended by entry/exit actions as introduced 
below. 

• Internal Transitions with Entry/Exit Actions : In order to support internal 
transitions i.e. execution of internal actions during all the time an object stays in 
the same state, it will be possible to inhibit automatic expansion of entry and 
exit actions by means of a specific syntactic rule for state and next state naming. 

• Internal Concurrency : The usual way in SDL to express internal concurrency 
i.e. parallel activities defined within the same Statechart, is to refine the object 
in separate processes, each process implementing one parallel activity. Internal 
concurrency within the same SDL process has not been implemented. 
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• Inheritance : The Statechart notation does not support inheritance. Therefore 
inheritance will only be allowed in standard SDL constructs, but not used in the 
Statechart extensions that have been implemented. 

• Dynamic Semantics : 

■ Each concurrent class (process) has its own Statechart, i.e. a Statechart 
corresponds to a process. This differs from pure Harel's Statechart - one 
Statechart model for the whole model - but this conforms to the UML 
Statechart variant. 

■ The dynamic semantics will conform to the SDL standard: asynchronous 
point-to-point communication, no broadcasting, each finite state machine 
has one queue that stores the events received but not yet consumed, 
dynamic process instance creation. 



4. SYSTEM PARTITIONING 

One of the key issues in the co-design of complex systems is the action of 
partitioning. The decision of which parts will be implemented in software and which 
will be transferred in hardware is crucial for the efficient implementation of the final 
system. Even though several prototype tools already exist for system partitioning, 
most of them are nothing but simple SDL-to-VHDL translators that produce a 
description that may feed existing RTL synthesis systems. In the context of the 
proposed methodology, the hardware-software partitioning is performed using 
COSMOS toolset, which is presented in the sequel. 



4.1.User guided system transformational partitioning 

The approach for SDL to CA^HDL proposed within COSMOS environment is built 
around an intermediate format called SOLAR [4, 11], designed to represent both the 
system concepts as well as those used by hardware description languages. The 
intermediate format SOLAR constitutes an intermediate representation permitting 
the unification of different specifications described in either hardware, software or 
system description languages. Thus, the different parts of software and hardware of 
a system can be unified within a single SOLAR format. SOLAR supports three 
levels of abstraction: the system level, the behavioural level and the Register 
Transfer Level. In addition, this model facilitates the reuse of existing sub-systems 
in the form of a library of components and communication models. SOLAR is used 
as an intermediate format during synthesis and is completely transparent to the 
designer. 

The basic construction within SOLAR is a state table denoted by the keyword 
StateTable. It permits the specification of hierarchical and communicating finite 
state machines. In addition, other structures are added to give a modular 
specification and facilitate the communication between the processes. The design 
unit (DesignUnit) is introduced for structuring a system into a set of interconnected 
subsystems. The channel unit (ChannelUnit) permits the specification of 
communication between the communicating subsystems. 
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The translation approach adopted is based on the correspondence between the basic 
concepts in the two languages SDL and SOLAR. Concepts used in SOLAR and in 
SDL, permits us to observe certain similarities. Nevertheless, SDL describes the 
behaviour at a level sufficiently abstract, whereas, the SOLAR descriptions, even if 
they are at a high level, are implementation oriented. The translation process 
proposed essentially works with the behavioural, communication and structure 
aspects of the specified system. Since SDL design system is in front of COSMOS, 
basic concepts of SDL are supported in COSMOS. The following table lists the 
subset SDL supported by COSMOS. Synthesis is the final stage performed on the 
SOLAR representation and translation into VHDL, for the hardware components 
and into C, for the software components. 



Table 2. SDL primitives to SOLAR primitives mapping 





SDL 


SOLAR 


Stmcture 


System, blocks, processes 


Done 


Communication 




Done 


Hierarchical specifications 




Done 


Declarations 


Data type 


Limited to: Del, synonym, 
newtype, literal, stmcture sort 




Exp/imp procedures 


Done 




Shared variables 


Done 




ADTs + operators 


Done 


Process/Procedure bodies 


State tables 


Done 



The organisation of partitioning into several small steps reduces the complexity of 
the problem. The designer controls the partitioning history within an interactive 
environment, through fine grain control of the synthesis process. This methodology 
can be seen as a human guided compilation where the designer spends additional 
effort to produce an efficient implementation. To facilitate the user's interaction for 
incremental transformations, all these refinements make use of a set of primitives 
called split, merge, move, flat and map allowing to decompose and transform 
objects. Figure 3 summarises these partitioning primitives. 

The user guided transformational partitioning assumes that the designer starts with 
an initial specification and an architectural solution in mind. System design from 
specification to implementation is performed through a set of primitives allowing 
the designer to transform the system, following an incremental refinement scheme, 
in a distributed model that matches the architectural solution. All the refinement 
transformations are performed automatically. Additionally, the decisions are made 
by the designer who uses his knowledge and experience to achieve the desired 
solution. 

4.2.Architecture generation 

The architecture generation translates the intermediate format used in COSMOS into 
executable code (C and VHDL) to allow the co-simulation and co-synthesis of the 
system. The virtual prototype generated is a heterogeneous architecture composed of 
a set of distributed modules, represented in VHDL for hardware elements and in C 
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for software elements, communicating through communication modules from a 
library of components. The virtual prototype is a simulatable model of the system 
that implements or emulates the initial specification. The generated model allows to 
separate the behaviour of the modules (hardware and software) and the 
communication units. Inter-module interaction is abstracted using communication 
primitives that hide the implementation details of the communication units. 
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Figure 3. Partitioning primitives used in COSMOS 



4.3.CA^HDL co-simulation interface 

In the context of the proposed methodology, co-simulation is reckoned as the joint 
simulation of a system description based on heterogeneous notations, since different 
parts of the system may be described using different notations. The rationale of 
adopting multiformlism is that, (a) when dealing with overall system specification, 
the use of multiple formalisms is desirable since it allows describing different 
aspects of the system with the most appropriate notation, and (b) when dealing with 
the virtual prototype of the system we need at least two different notations for 
describing efficiently the hardware and the software parts respectively. 

The COSMOS environment generates a distributed hardware/software co-simulation 
environment for heterogeneous systems prototyping. The environment provides as 
features: distributed hardware/software co-simulation and automatic 

hardware/software interface generation. Hardware components can be described at 
different levels of abstraction and generic/specific software debuggers can be used. 
Starting from a brief description of the interface of the interconnected modules, an 
operation named communication synthesis produces automatically the interface 
between hardware and software parts. 
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The distributed co-simulation environment is composed of a VHDL simulator (VSS: 
VHDL SYNOPSYS Simulator) for hardware components and C-debuggers (any 
tools in the market) for software modules communicating via a software bus. This 
bus relies on the UNIX IPC layer. The software bus and the elements used to 
interface VHDL and C modules during simulation are automatically created as result 
of communication synthesis. 




Figure 4. Overview of a wireless ATM system 



5. DESIGN OF A MAC LAYER PROTOCOL USING 
MULTIPLE FORMALISMS FOR SYSTEM 
SPECIFICATION 

The methodology proposed within this paper has been used to develop a MAC layer 
protocol named MASCARA [9] for offering ATM services over wireless 
connections. The wireless ATM architecture consists of ATM switches, Access 
Points and Mobile Terminals as shown in Figure 4. ATM switch is a standard 
customer premises access node, containing also mobility specific software and 
minimum hardware modifications; Access Point is the network element connected to 
the ATM switches with standard ATM connections; finally, Mobile Terminal is the 
end-user equipment that contains the wireless ATM radio adapter card, interfacing 
the 20 Mbits/sec air-interface. 
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For connection admission MASCARA provides information on link conditions 
including e.g. the available bandwidth and cell error ratio. The actual call admission 
is made taking into account existing connections, the radio link condition and spare 
capacity required for handovers. The scheduler of the protocol is designed to 
preserve the admitted connections as conformant as possible within the negotiated 
connection QoS parameters. The service policy implemented by the scheduler can 
be tuned to meet the needs of a particular installation or a particular set of users. 

5.1.System specification 

The first stage of the protocol design involves requirements capturing using UML 
[2]. The reason for using UML lies in the fact that significant parts of the protocol 
are already available as standards in UML. So having available standard parts of the 
protocol, like SAR (Segmenting and Reassembly) unit, we are able to reduce the 
amount of work needed for designing them (we use them either as they offered or 
with minor changes). Figure 5, presents a high level specification of MASCARA 
using UML, while Figure 6 depicts the internal behaviour of the “Control 
Segmenting and Reassembly” object using Statecharts (UML uses Statecharts for 
describing the dynamic behaviour of the objects composing a system specification). 
Due to limited space, we have restricted our specification only to the essential parts 
of the protocol, while for shake of simplicity we have intentionally eliminated the 
references among the constituent parts of the protocol. Among the objects 
composing the MAC layer, ATM Layer corresponds to the ATM layers above 
MASCARA that implement the classical ATM services; Physical Layer implements 
functions pertaining to the actual physical layer (in our case the transmission 
medium is air) of a traditional protocol stack; the remaining objects are part of the 
MASCARA specification and incorporate aspects concerning mobility. 

The final stage of the specification involves description of the protocol’s parts using 
SDL (Figure 7 reflects part of the UML specification presented in Figure 5). The 
objects have been transformed in blocks and their internal behaviour has been 
implemented using SDL structures (see Table 1). Having completed the system 
specification using objects, we transform them automatically to SDL adding the 
necessary implementation details for having a more detailed version of protocol’s 
specification. This way, we combine of-the-shelf components described in UML 
with newly created components described in a powerful language like SDL. Having 
a detailed system specification in SDL, we are able to exploit the power of state-of- 
the-art tools like ObjectGeode which incorporates a set of powerful utilities for 
SDL-to-Statechart translation, exhaustive simulation, deadlock detection etc. So, we 
are able to verify/validate the system’s specification early enough in the co-design 
flow, where the cost of repairing possible design flaws is relatively small. 
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Figure 5. The constituent parts of the MASCARA protocol in UML 




Figure 6. Statechart representing the dynamic behaviour of 
“Control Segmenting and Reassembly” object 
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5.2.System partitioning 

This section refers to HAV-SAV partitioning of the MASCARA protocol. We will 
illustrate the overall design flow in COSMOS, from the system-level specification 
given in SDL to the distributive hardware/software architecture described in 
CA^HDL. The use of SDL allows for fivefold reduction of the size of system’s 
specification when compared to distributed CA^HDL models. All the transformation 
applied in this section are fast enough to look instantaneous during an interactive 
session. 




Figure 7. Specification of a small part of the MASCARA protocol in SDL 



The SOLAR intermediate format is obtained by an automatic conversion from the 
initial SDL description. During the conversion, the following operations are 
performed: processes are converted to design units, processes behavior are converted 
to state stables and interconnections among SDL processes are converted to abstract 
channels. Figure 8 depicts the initial SOLAR model. The refinement steps 
performed for the production of the MASCARA protocol’s virtual prototype, are 
listed in the sequel: (a) structural flat to keep out the hierarchy of all the design 
units, (b) protocol selection, where a communication protocol is chosen from a 
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protocol library (the FIFO and rendez-vous protocols were chosen to implement all 
the abstract channels), (c) channel map, where the abstract channels were replaced 
by well defined signals interfaces, (c) hardware/software assignment, where (after a 
trial and error approach) the processes WDLC and SCH and the FIFO controller of 
WDLC are set to have a software implementation. The processes TB, MPDU and 
the others FIFO controllers are set to have an hardware implementation. 

Summing up, the SDL specification has been transformed to SOLAR so as to enable 
efficient system partitioning. Each process has been represented as a design unit 
whose internal behaviour has been specified using a state table (which is the 
conceptual equivalence of the an FSM in SDL or a Statechart in UML). The 
communication scheme among the various design units have also been specified 
more accurately by selecting specific protocols for implementing their 
communication. For example, the concept of channels or signal routes that connect 
two system blocks in SDL are no longer abstract. In fact, the channel notion 
incorporates concepts such as communication protocols (e.g. FIFO, Rendez-Vous, 
etc) and specific bus (channel) arbitration schemes. 




S tate 

wnjic_FpeehKw>ii 




Figure 8. Intermediate model resulting from the partitioning 
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5.3.Virtual prototype 

The distributed CA^HDL co-simulation environment is composed of a VHDL 
simulator for hardware modules and C-debuggers for software modules. Each C 
debugger is interconnected to the VHDL simulator through a software bus which 
relies on the UNIX IPC layer. The software bus and the elements used to interface 
VHDL and C modules during simulation are automatically created by the CA^HDL 
interface generation tool. The distributed CA^HDL co-simulation environment is 
detailed in Figure 9. 

The VHDL structure is simulated through a VHDL simulator, while the programs, 
the design units and the controllers are executed by C debuggers (external boxes on 
Figure 9). Each program uses C procedures that implement the actual data exchange 
between the VHDL simulator and the C programs through a set of I/O primitives 
based on Unix-IPC channel. 




Figure 9. C/VHDL co-simulation scheme for the MASCARA protocol 
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6. CONCLUSIONS 

In the previous sections we presented a co-design methodology for embedded 
systems design, where the concept of system specification using multiple 
formalisms was introduced. A platform for coupling different notations was 
introduced and, the necessary mechanisms to handle different in nature models in a 
coherent way were presented. The specification languages supported refer to a wide 
area of application domains, enabling selection of the mostly appropriate formalisms 
for a specific application. The co-design development cycle presented, provides a 
fully fledged methodology that leads from system specification to a virtual prototype 
of the system under construction, where the software parts are implemented in C and 
the hardware parts are implemented in VHDL. The efficiency of the proposed co- 
design approach is depicted through its use for the design and implementation of a 
MAC layer protocol, named MASCARA, for providing ATM QoS over wireless 
connections. The protocol has been designed using UML and SDL as 
complementary formalisms for requirement capturing. The system partitioning and 
the creation of a virtual prototype of the final system has been based on the 
COSMOS toolset and the system description in the SOLAR notation, the underlying 
formalism supported by COSMOS. 
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Abstract: 

In this paper, we propose a technique for hardware implementation of protocol speci- 
fications in LOTOS. For the purpose, we define a new model called synchronous EFSMs 
consisting of concurrent EFSMs and a finite set of multi-rendezvous indications among 
their subsets, and propose a conversion algorithm from a subset of LOTOS. The de- 
rived synchronous EFSMs can be easily implemented as a synchronous sequential circuit 
where all the modules corresponding to the EFSMs work synchronously with the same 
clock. By applying our technique to the Abracadabra protocol, it is confirmed that the 
derived circuit handles multi-rendezvous efficiently. 

1 INTRODUCTION 

Due to the growth of computer networks, efficient implementation of communication 
protocols has been needed. Thus, the techniques for implementing protocols as hard- 
ware circuits have been stressed in recent years. 

To specify hardware circuits formally, the description techniques LOTOS [1, 12], 
Estelle [15] and SDL [13] have been proposed. With these techniques, we can eas- 
ily describe schemes for hardware circuits using predefined component libraries, and 
can verify/validate them. However for rapid prototyping, synthesis techniques from 
the specifications are desirable. Several ideas for hardware synthesis from formal 
specifications have been proposed [6]. For example, [15] has proposed a synthe- 
sis technique from Estelle. However, the technique does not deal with the highly 
structured specifications containing synchronization among concurrent modules like 
multi-rendezvous. In [7], although a technique to convert timed LOTOS specifica- 
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tions to VHDL specifications has been proposed, only two-way rendezvous between 
two processes is implemented. [1 1] has also proposed a technique to synthesize hard- 
ware circuits from LOTOS specifications, but focuses only on Basic LOTOS. Since 
LOTOS specifications are structurally composed of multiple sub-processes which are 
dynamically invoked, participants of each multi-rendezvous may be decided dynam- 
ically each time. In general, for efficient implementation it is desirable that we can 
transform complicated LOTOS specifications into ones on a flattened model like an 
EFSM which has no child-parent relationships between processes. It is also important 
to calculate in advance all the information about the combinations of synchronizing 
processes, the tuples of synchronizing events and their execution conditions. For the 
purpose, [10] has proposed a method to derive all possible multi-rendezvous instances 
from a LOTOS specification. However, the method requires the complete reachability 
analysis among all parallel processes, which needs time proportional to the product of 
the numbers of events in those processes. 

In this paper, we propose a technique for hardware implementation of protocol 
specifications in a subclass of LOTOS where choice, synchronous/asynchronous par- 
allel, interruption, sequential composition and dynamic process instantiation are spec- 
ified with data. For the purpose, first we propose a new model called synchronous 
EFSMs [16] for representing LOTOS specifications. Synchronous EFSMs consist of 
concurrent EFSMs and a finite set of multi-rendezvous indications for their subsets 
(we call the set a multi-rendezvous table). In general, if we use all possible ren- 
dezvous instances (i.e., tuples of synchronizing transitions) as the multi-rendezvous 
table, the number of elements will be quite large. In our model, we reduce the number 
by composing each rendezvous indication of the tuple of possible event sets. Next, 
we give an algorithm to derive synchronous EFSMs from a protocol specification in 
our subclass of LOTOS. In the algorithm, we transform a given LOTOS specification 
to the parallel composition of EFSMs by introducing internal signals and by replacing 
each process instantiation with the corresponding behavior expression. We get a multi- 
rendezvous table statically from the information about transitions in each EFSM, and 
parallel operators specified among EFSMs by calculating all combinations of EFSMs 
synchronizing at each gate and by extracting all possible tuples of transitions. 

To implement synchronous EFSMs as a synchronous sequential circuit, we com- 
pose a module to evaluate whether each rendezvous indication has an executable tran- 
sition tuple or not. If several mutually exclusive multi-rendezvous become executable 
simultaneously for some combinations of EFSMs, we select one of them according to 
a priority order given in advance. 

In Sect. 2, we introduce system design in LOTOS and give the definition of syn- 
chronous EFSMs. An algorithm to derive synchronous EFSMs is given in Sect. 3. 
Sect. 4 and 5 present a hardware implementation technique and its evaluation. 

2 LOTOS AND SYNCHRONOUS EFSMS 
2 . 1 System design in LOTOS 

In a LOTOS specification, we specify a behavior expression of the protocol consist- 
ing of events and their temporal order. To specify the temporal order of events, we 
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Figure 1 Network switch 



use several operators in LOTOS such as action prefix (which combines events in se- 
quential order) as well as choice, parallel, sequential and disabling between any two 
sub-behavior expressions. In a LOTOS specification, we can replace any sub-behavior 
expression by a process instantiation. It means that we can compose the whole behav- 
ior expression as the set of structured modules. (See [3] for details of LOTOS) 

Especially, parallel operators and process instantiations make it easy to describe 
system specifications both structurally and simply. Multi-rendezvous enables group 
communication among any subset of concurrent processes, which drastically reduces 
communication actions in specifications. Multi-rendezvous also enables system spec- 
ifications in constraint/resource oriented style [14] where we can design a system as a 
set of simple modules, and develop each module independently of the others. 

For example, let us design a network switch in LOTOS which has the following 
requirements: the switch has three ports a, b and c which are connected to different 
networks A, B and C, respectively (see Fig. 1). Each data packet arriving at the switch 
should be forwarded to the appropriate network based on its destination. Here, we 
route the packets based on the intervals: i.e. if the packet’s destination is in the in- 
terval [1, A/'l), the packet should be directed towards network A (via port a); if in 
the interval [Nl, N2), towards network B; if in [A^2, oo), towards network C. If the 
switch receives the packet with the destination 0 (i.e. broadcast), the packet should be 
broadcasted to all ports except for its reception port. In addition, we suppose networks 
A and B use the same protocol (e.g. IP), but network C uses a different protocol (e.g. 
AppleTalk). That means the switch should have the facility for protocol conversion of 
each packet from either A or B to C (and vice versa). 

It is desirable to design the behavior of each port independently of the others. For a 
better response time, input and output behaviors for each port should be able to work 
in parallel. In addition, in order to allow asynchrony among ports we use a FIFO 
queue shared among them. Here, we introduce three internal ports qi, qo and m for 
the access to the queue. We suppose a new packet can be added to the queue via qi 
and the packet in the queue can be taken via qo in FIFO manner (see Fig.l). Although 
m is used in the same way as qo, it is dedicated to the purpose of broadcast. 

According to the above discussion, LOTOS processes (PI and P2) for ports a and 
b are described as follows: 
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Pl[a,qi,qo,m] (11,12) :=Il[a,qi] | | |ol[a,qo,m] (11,12) 
where 

Il[a,qi] := a?idt : IP; gi ! idt ; II [a, qi] 

Ol[a,qo,m] {11,12) : =qo?odt : IP [ll<=dst (odt) <12] ;a!odt;01 [a,qo,m] (11,12) 

[] m?odt:IP[ll<=src(odt)<12] ;01 [a, qo,m] (11,12) 

[] m?odt:IP[not(ll<=src{odt)<12) ] ;a!odt;01 [a,qo,m] (11,12) 

P2 [b, qi , qo,m] (11,12) : =P1 [b, qi , qo,m] (11,12) 

(here, dst{data) and src{data) are the ADT functions to get the destination and the source of the packet 
data, respectively. 11 <= x < 12 represents that the value of x is in the range of [11,12). P2 is de- 
scribed as an instantiation of PI) 

Inputs/outputs via port c needs protocol conversion. So, for port c, we slightly 
modify the above process as follows: 

P3 [c,qi,qo,m] (11, 12 ) : =13 [c, qi] | | 1 03 [c, qo,m] (11,12) 
where 

13 [c, qi] : =c?idt : Atk; qi ! convIP (idt) ; 13 [c, qi] 

03 [c,qo,m] (11,12) := 

qo?odt : IP [ll<=dst (odt) <12 ] ;c !convAtk(odt) ;03 [c,qo,m] (11, 12) 

[] m?odt:IP[ll<=src(odt)<12] ;03[c,qo,m] (11,12) 

[ ] m?odt : IP [not (ll<=src (odt) <12 ) ] ; c ! convAtk(odt) ;03 [c, qo,m] (11,12) 

(here, convIP{) means the conversion of the packet to IP, while convAtk{) to AppleTalk) 

Next, we need a coordinator for the FIFO queue. We describe the queue and its 
operations by an ADT in LOTOS. The coordinator stores a new packet coming to qi 
to the queue, or outputs to port either qo or m the last entry in the queue based on its 
destination. The process Crd for the coordinator can be described as follows: 

Crd[qi,qo,m] (queue) := 

[size (queue) <MAX] ->qi?data: IP;Crd[qi,qo,m] (append (queue, data) ) 

[ ] [dst (head (queue) ) ==0] ->m! head (queue) ;Crd[qi,qo,m] (tail (queue) ) 

[ ] [not (dst (head(queue) ) ==0] ->qo! head (queue) ;Crd[qi,qo,m] (tail (queue) ) 
(here, size(),append{),head{) and tail{) represent ADT functions for the queue operation. MAX is 

the maximum number of entries in the queue) 

Finally, we specify the interaction among the above processes. In general, we have 
to design the mutual exclusion mechanism for the queue since some parallel processes 
may access it at the same time. However, in LOTOS, we can simply describe such a 
mechanism with multi-rendezvous as follows (here, INF denotes oo): 

specification Switch[a,b,c] := 
hide qi,qo,m in 

(PI [a, qi , qo,m] (1,N1) | [m] | P2 [b, qi , qo,m] (N1,N2) | [m] | P3 [c, qi, qo,m] (N2, INF) ) 
1 [qi,qo,m] | 

Crd[qi, qo,m] 

In the above specification, one of PI, P2 or P3 synchronizes with Crd to store/get 
a packet to/from the queue via internal ports qi/qo. When the packet’s destination is 
0, all of PI, P2 and P3 get the packet at the same time by multi-rendezvous on m. 

2.2 Synchronous EFSMs 

Synchronous EFSMs are the model where any subset of concurrent EFSMs can com- 
municate with each other via gates by multi-rendezvous[16]. 

Synchronous EFSMs are given as a set of EFSMs {efsm^,..., efsm.^} and a multi- 
rendezvous table TZ. We suppose that each EFSM can have a finite number of registers. 
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Table 1 Synchronization condition. 



Pi 


Pi 


condition 


result 


g\Ei 


g'-Ei 


11 


— 


g\Ei 


g?x : t 


val(Ei) G domain(t) 


X i- val(Ei) 


g?x : t 


g?y : u 


t = u 


X, y 4- Ext, Ext e domain(t) 



iyal{E) is the normal form of E, Ext is the value input at gate g) 



that a certain execution condition called a guard expression can be specified to each 
transition (i.e. edge), and that each transition can perform several substitutions for the 
registers in parallel. 

In LOTOS, multi-rendezvous is specified by just giving abstract relationships among 
concurrent processes by parallel and other operators. For the efficient implementation 
of multi-rendezvous, we should calculate in advance the information about the com- 
binations of synchronizing EFSMs, the tuples of synchronizing transitions (synchro- 
nization tuples) and their execution conditions. If we represent the multi-rendezvous 
simply by the set of all the combinations of transitions in synchronizing EFSMs, the 
number will be where n and k are the number of EFSMs and the number of 

transitions in an EFSM, respectively. 

Therefore, in our model, we represent all possible multi-rendezvous instances by 
a set of rendezvous indications where each indication is a tuple of transition sets on 
a gate for a combination of synchronizing EFSMs. Here, every combination of tran- 
sitions (called synchronous tuple) in the sets has the possibility to be executed by 
multi-rendezvous (i.e. every synchronous tuple satisfies the condition in Table 1). 

We denote each rendezvous indication by ((JSi , • • • , Em), {M , • • • , Am)) where 
(E\^ • • • , Em) is a tuple of synchronizing EFSMs, and each Ai is the synchronous 
transition set which contains transitions executed in Ei for the rendezvous. We repre- 
sent elements of Ai as the triples (a, p, I). Here, a is the transition name consisting 
of a gate name and input/output parameters, p is a guard expression, and I is the set of 
substitutions to undefined variables. 

Criteria for each rendezvous indication 

To implement multi-rendezvous efficiently, we adopt the following criteria for each 
rendezvous indication {(Ei , ..., Em), (Ai , ..., Am)): (1) all transitions in each A{ must 
be either all input transitions (p?) or all output transitions (p!); (2) each Ai must not 
contain transitions with different kind of output values which are executed at the same 
state (i.e. if two transitions a!Vi and a!V 2 are executable at a state, we assign them to 
different rendezvous indications); and (3) at most one Ai of (Ai , ..., Am) can have a 
set of output transitions. 

By the above criteria, we can easily know in each rendezvous indication what 
EFSM outputs some values and what other EFSMs expect the values as their inputs. 
This contributes to implement data paths to transfer the values among related EFSMs 
to evaluate the synchronization condition. 

The above criteria are not restrictions since we can automatically get the rendezvous 
indications satisfying them as we will explain in Sect. 3. 

By using the above technique, each rendezvous indication ((J?i , • • • , Em), 

(Ai , • • • , Am)) can represent a maximum of YViLi \^i\ rendezvous instances (here, 
\Ai\ means the number of elements in Ai). Consequently, the number of elements in 
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the multi-rendezvous table and the time to calculate the table are bound to 0(p • fc • n) 
where p is the maximum number of combinations of the synchronizing EFSMs on a 
gate (usually p can be considered as a constant) and k • nis the sum of the numbers 
of the output transitions with different values in EFSMs (in the worst case, k • n may 
be the number of all transitions in EFSMs). For example, for EFSMl | [a, b] |EFSM2 in 
Fig. 4, ten rendezvous instances could be produced. With the above technique, we can 
reduce the number of tuples to three as shown in Table 3. 

Behavior of synchronous EFSMs 

We call each transition e in an EFSM Ei an asynchronous transition \i e ^ A{ 
for every rendezvous indication ((£?i, ...,Eyn), (Ai, ...,^rn)) G E.. We define an 
asynchronous transition to be executable when the current state has the corresponding 
outgoing edge. 

For a rendezvous indication r = {{E\, • • • , Em), (Ai, • • • , Am)), if each Ei 
is in a state to execute the transition Ci e Ai and the execution condition of ei 
is true, then the synchronous tuple (ei, • • • , Cm) can be executed. Whether a syn- 
chronous tuple (ei, • • • , Cm) can be executed or not is decided by checking the ex- 
istence of the rendezvous indication which contains such a synchronous tuple. For 
different two rendezvous indications r i = {{Ei , • • • , Em), (Ai , • • • , Am)) and r 2 = 
((E{ , • • • , El), {A [ , • • • , A{)) G TZy suppose that at least one EFSM is the common 
member of both ri and r 2 . In that case, such an EFSM has to decide to execute the 
transition in either ri or r 2 . We say that ri conflicts with r 2 if they can offer the 
different synchronous tuples at the same time. 

Here, we explain how synchronous EFSMs work in cooperation, using an example 
in Fig. 2. In Fig. 2, the dotted line shows that one of EFSMl, EFSM3 and EFSMS can 
synchronize with EFSM7 on gate qi at the same time (one of EFSM2, EFSM4, EFSM6 
on gate qo)\ the solid line shows that EFSM2, EFSM4, EFSM6 and EFSM7 can syn- 
chronize with each other simultaneously on gate m. In the initial state {si, si, si) 
of EFSMl, EFSMS and EFSM7, they have the outgoing transitions alidt, clidt and 
qi?data[size (queue) < MAX], respectively. The first two transitions are asyn- 
chronous, so they are executed independently of the other EFSMs when the input data 
come to the gates. When alidt is executed in EFSMl, the current state is changed to 
(§ 2 , si, si). In the state, EFSMl and EFSM7 have the outgoing edges qilidt and 
qi?data[size(queue) < MAX], respectively. Since queue contains nothing ini- 
tially, the execution condition size(queue) < MAX holds. Therefore, the tuple 
(qilidt, qi?data[size(queue) < MAX]) can be executed by the rendezvous indica- 
tion (1) of Fig. 2. When the tuple is executed, the value of idt is assigned to the 
undefined variable data, and the current state is changed to (si, si, S 2 ) in EFSMl, 
EFSM5 andEFSM7. 

In some state, there may be several synchronous tuples to be executable simulta- 
neously. For example, in Fig. 2, when the current state is (si, s\, Si) for EFSM2, 
EFSM6 and EFSM7, a synchronous tuple (qolodt \dst(odt) < Wl], qo\head(queue) 
[dst(head(queue))\ = 0]) could be executed between EFSM2 and EFSM7 by the 
rendezvous indication (4) as well as (qolodt [N2 < dst(odt)], qo\head(queue) 
[dst(head(queue))\ = 0]) between EFSM6 and EFSM7 by the rendezvous indication 
(6). In that case, one of them must be selected by consensus of the related EFSMs. 
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No. 


tuple of 

EFSMs 


tuple of synchronous transition sets 


(1) 


(1,7) 


{{(qilidt, true,—)}, {{qildata, size{queue) < MAX, data <r- idt)}) 


(2) 


(3, 7) 


{{(qilidt, true,—)}, {{qPdata, size{queue) < MAX, data -f- idt)}) 


(3) 


(5, 7) 


({(qi\convIP{idt), true, — )}, 

{{qPdata, size{queue) < MAX, data <- convIP{idt))}) 


(4) 


(2.7) 


({(qolodt, dst{odt) < Nl, odt i- head(queue))}, 
{(qo\head{queue),dst{head(queue))\ = 0, — )}) 


(5) 




{{{qo?odt, Nl < dst{odt) < N2,odt <— head{queue))} , 
{{qo\head{queue), dst{head{queue))\ = 0, — )}) 


(6) 


(6,7) 


({iqolodt, N2 < dst{odt), odt head{queue))} , 

{{qo\head{queue), dst{head(queue))\ = 0, — )}) 


(7) 


(2, 4, 6, 7) 


{{{m?odt, src{odt) < Nl, odt <r- head(queue)), 

(m?odt, not{src(odt) < Nl), odt head(queue)) }, 
{{m?odt, Nl < src(odt) < N2,odt head{queue)), 
(m^odt, not{Nl < src(odt) < N2), odt ^ head(queue))} , 
{{m?odt, N2 < src(odt), odt •<— head{queue)), 

{m?odt, not(N2 < src(odt)), odt <r- head(queue))} , 
{{m\head{queue), dst{head{queue)) == 0, — )}) 



Figure 2 Example of synchronous EFSMs 

3 DERIVING SYNCHRONOUS EFSMS 
3. 1 Preliminaries 

In this paper, we consider any LOTOS specifications represented in the class of Table 2 
although we impose the following restrictions on process instantiations. 

• Recursive processes are allowed when they are tail recursion (e.g. P := B » P). 

• Recursive processes which may produce infinite behavior such as P := (PI >> 
P >> B2)\\exit or P := P op P {op E {[], |[G]|, [>}), are not allowed. However, 
if the recursive process call is guarded and the guard expression can be evaluated 
statically (e.g. P{x) := P|||([x < 100]- > P{x + 1))), we treat such a process. 

• Mutually recursive processes are allowed as long as process calls are guarded and 
the guard expressions can be evaluated statically. 

Let #Par(P) be the function that represents how many parallel processes can be 
activated at the same time in a behavior expression P. We say a behavior expres- 
sion P is a sequential behavior expression (SBE) if #Par(P) = 1 and P includes 
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Table 2 Target class of LOTOS 



BO ::= 


hide G in B1 1 let value declarations in B1 | B1 


B1 ::= 


B1 » B2 1 B2 


B2 ::= 


B2[> B3 1 B3 


B3 ::= 


B3|||B4 1 B3||B4 | B3|[G]1B4 | B4 


B4 ::= 


B40B5 1 B5 


B5 ::= 


[boolean exp] — > B6 | B6 


B6 ::= 


event] B [ stop | exit | (Bl) | P[G]{el) 


event ::= 


gate | gate val | gate val [boolean exp] 


G::= 


gate | gate^G 


val ::= 


Ivarname : sort val \ \exp val 


exp ::= 


(* every expression written in ACT ONE *) 


el ::= 


exp, el 



only action prefixed sequences, their choices and iteration. We use St{B) to refer 
the set of the initially executable events in B. We denote the behavior expression 
by n::i Si,andBiO...DB, by Bi. 

3.2 Transformation algorithm 

We transform Bmain to the parallel composition among SBEs by applying the follow- 
ing operations recursively to its sub-behavior expressions: (1) replace each process 
instantiation with its behavior expression unless the instantiation appears as a tail re- 
cursion (i.e. P := B » P); (2) transform each action prefixed sequence Bad such 
that H:Par{Bad) > 1 into the parallel composition among sequential behavior ex- 
pressions (SBEs); (3) transform each choice/disabling/sequential composition among 
sub behavior expressions into either an SBE or a parallel composition among SBEs. 

For (1), we replace each process instantiation P[G]{V) appearing in its behavior 
expression Bp as a tail recursion, with the iteration of Bp by introducing label(P[G]): 
and goto(P[G],X:=V). Although other process instantiations are replaced with their 
behavior expressions even if they are recursive processes, they are not infinitely in- 
stantiated by the restriction in Sect. 3.1. 

We show the transformation algorithm Trans below. Here, pset is the set of pro- 
cess instantiations already replaced with their behavior expressions. 

Algorithm Trans{B^ pset) 
begin 

if (B = ai; B', B' ^ a'\B") then 
if (#Par(B') > 2) then 
Trans{B' , pset) 

TransAct(B) 

endif 

else if (B = [guard]— > B') then 
if {guard is true or cannot be calculated statically) then 
Trans{B') 
endif 

else if {B = ^ Bi) then 
for each i, Trans{Bi , pset) 

TransChoice{B) 
else if(B = Bll[G]|B2) then 
Trans{Bl^ 0); Trans{B2, 0) 
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else if {B = Bl[> B2) then 
Trans{Bl^pset);Trans{B2ypset);TransDis{B) 
else if {B = Bi » ...» Bk) then 
for each i < k, Trans{Bi , 0) 

Trans{Bk’,pset) 

TransSeq{B) 
else if(B = F[G](V^)) then 
if {P[G] G pset) then 
replace P[G]{V) with goto(P[G],X:=V) 
else 

replace P[G]{V) with label(P[G]): let X:=V in Bp^c] 

Trans{Bp[Q^yPsetU {P[G]}) 
endif 
endif 
end 

The sub-procedures used above are given below. 

Trans Act: transformation of action prefixed sequence. For Trans Act, 

def 

ai; {Bi\[Gi]\...\[Gn-i]\Bn){ = Bact) is given. Here, each Bi is an SBE be- 
cause Trans transforms each sub-behavior expression which is not an SBE to the 
parallel composition of SBEs recursively. In B act ^ each Bi should be activated after 
ai is executed. Accordingly, we assign the event sequence ai; ...; a/ and the behavior 
expressions 5 i , ..., Bn to different SBEs, respectively. Then, we introduce an internal 
signal 6 so that the SBE for ai; ...; ai sends the signal 9 to other SBEs after the exe- 
cution of ai and that the SBEs for Bi, ..., Bn are activated when they receive 9. We 
specify the exchange of 9 by multi-rendezvous among the SBEs. Consequently, B act 
is represented by the parallel composition of SBEs as follows: 

ai;...;a/;0; exit\[9]\{9;Bi\[{9}UGi]\9;B2\[{9}UG2]\...\[{9}UG^ 

TransChoice: transformation of choice expression. For TransChoice{B cho)^ 
Bcho is given as j, Bj can be represented by Yll^i ^j,i where 

each B' j is an SBE. If mj = 1 for each i, Bcho is a SBE. Here, we consider the 
case nij > 1 for some j (i.e. parallel operators are specified in Bj). We suppose 

de f 

each Bj^ to be an action prefixed sequence without losing generality. Let Bj = 
CLj^i; Bj^i. We call each Bj the j-th group. Let mx be the maximum number 
among mi, ...,mn- 

In choice, any pair from different groups cannot be executed at the same time. 
Therefore, we can assign Bcho to mx SBEs. Although there are various ways of as- 
signment, here we extract an SBE from each group j{l < j < n), and compose a new 
SBE of the choice among the extracted n SBEs. For the sake of simplicity, we assign, 
to each new i-ih SBE, z-th elements of all groups (if there is no i-th element, exit is used 
instead). In Fig. 3, the pairs from Bi [] B2: (an; Bn, a2i; B21), (a^; Bn, a22;B22) 
and (exit, a2s; B23) are assigned to new SBEs, where BI an; Bn ||| ai2; Bn and 
B 2 := a2i; B21 ||| a22j B22 ||| a 23 j B23. 

Next, we introduce a mechanism to keep the equivalence between the new behavior 
expression and the old one. Let us suppose that the j-th element has executed in one of 
the new mx SBEs. This means that the j-ih group has selected in Bcho- So, we have 
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Figure 3 Assignment and resulting SBEs in a choice expression 

to make only the j-th element execute in all the SBEs after that. To do so we add, to 
each new SBE, extra events for detecting what event has executed in other SBEs. We 
achieve those detections by the communication with multi-rendezvous among the new 
SBEs so that only first executable events in St{Bcho) synchronize among the SBEs. 
Accordingly, the following expression is produced for each SBE: 

n 

sbei = 

j—l aESt{Bj),a^aj^i 

Fig. 3 shows the resulting SBEs from the above example. Here, an or a\2 must be 
synchronized among the SBEs to detect that the group of J 51 has been selected (thick 
solid transitions), while U2i , a22 or 023 detects the group of B 2 (dotted transitions). 

TransDis, TransSeq: transformation for other operators. In disabling expres- 
sion Bi[> B2 (here, Bj YlT=i ^^ere is no possibility for SBEs in B\ 

and those in B2 to be executed simultaneously. So, we assign to a new SBE each 
pair of the z-th elements in B\ and B2. In each new SBE, we combine sbei^i and 
sbe2,i with choice operators so that events in sbei^i should be disabled if an event in 
sbe2^i is executed. Similar to the case of choice expressions, each SBE must be able 
to detect if such a disabling event is executed in other SBEs. To do so, we add to 
each SBE extra events for detecting the disabling events in St{B2), and specify multi- 
rendezvous so that those events should be synchronized among the new SBEs. By the 
above assignment each disabling expression is converted to the parallel composition 
of max(#Par(Bi),#Par(B2)) SBEs. 

For the sequential expression Bi » B2, similarly we extract each pair of SBEs 
from Bi and B2 and compose a new SBE. Here, we introduce internal signal S to 
indicate that all events in Bi have been executed and to activate the behavior corre- 
sponding to B2. With the multi-rendezvous of S, we make the new SBEs finish the 
execution of Bi at the same time as starting the execution of P2 - Pi >>•**>> P/ 
can be transformed in the same way. 

If the sequential expression has tail recursion in the process instantiation such as 
P[G]{X) := B » P[G]{V) and if #Par{B) > 1 , all the SBEs extracted from P 
have to get to their initial states when goto(P[G],X:=V) is executed. In that case, for 
each SBE, we add the transition to the initial state from the state after executing S with 
the corresponding subset of the substitutions of X:=V. 
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The details of the transformation algorithms and a simplified proof for its correct- 
ness are given in [16]. 

Calculation of Multi-Rendezvous Table 

Only synchronization operators are specified among EFSMs after applying the 
transformation algorithm. In this section, we give a technique to get the multi-rendezvous 
table from transitions in each EFSM and operators specified among EFSMs. From the 
syntax tree of the operators among EFSMs and gate names used in each EFSM, we 
can get the combinations of synchronizing EFSMs on each gate. If a multi-rendezvous 
is specified among a subset of EFSMs E on gate g, we denote that by Rend{£^ g). The 
finite set of all synchronous tuples as well as their execution conditions is statically 
determined if Rend{E, g) is given for all combinations of £ and g. Let RI be the 
union of Rend{£^ g) for all £ and g. We calculate the set as follows. 

For each Rend{£^ g) G RI^£ = {Ei, • • • , Em} ' (1) extract all transitions on 
gate g, for each Ei e £ (let syncjev{Ei, g) be the extracted transitions for Ei)\ (2) 
calculate the set of tuples {(ei, • • • , em)|ci G sync-ev{Ei, g)} where each tuple can 
satisfy the synchronization condition in Table 1 (let Tuples{£, g) denote the set). 

Next, we convert the synchronous tuples to rendezvous indications as follows, so 
that they satisfy the criteria in Sect. 2.2. For each Tuples{£, g ) : 

(i) calculate the set of output values OV where each value is assigned to undefined 
variables by the synchronization. 

(ii) for each Ei e £ and each v G OV, calculate the set of transitions A{ where each 
transition satisfies the synchronization conditions in Table 1 with v\ and compose a 
rendezvous indication of the tuple {£, {A i 5 * ’ ’ 5 Am)) • 

(iii) If Ai includes both input (g?) and output (g!) transitions, we divide such a ren- 
dezvous indication {£, (Ai, • • • , Am)) to {£, (Ai, • • • , • • • , Am)) and {£, (Ai, • • • , 

Af^^, • • • , Am)) so that each A-’^ (A^“^) includes only input (output) transitions. This 
operation is repeated until the elements of each A^(l < z < m) are all input transi- 
tions or all output transitions. 

(iv) If jBj G f has two different output transitions (i.e. g\V \ , gW^) in Ai from the same 
state, the rendezvous indication (f , (Ai , • • • , A^, • • • , Am)) is divided into {£, (Ai , • • • , 
Ai - {gWi},-- ,Am)) and (Ai, • • • , A* - {g\V 2 } , Am)) . This operation is 
repeated until each Ai has only one output transition from each state in Ei. 

(v) If a rendezvous indication (^, (Ai, • • • ,Am)) contains Ai and Aj such that the 
both sets have output transitions, we modify a transition in either A i or Aj to an input 
transition. For example, a\x |[a]| aly |[a]| a?z is transformed to a!a: \[a]\ a7w[w = 
y] IHI a?z. 

The above procedure could produce some rendezvous indications which contain 
impossible synchronous tuples since we do not use any reachability analysis tech- 
nique. A synchronous tuple can be executed as long as the synchronization condition 
of the tuple holds for a rendezvous indication. Not all synchronous tuples in each 
rendezvous indication can be executed. That means the multi-rendezvous table itself 
is a sufficient condition for implying the possible multi-rendezvous instances. In our 
model, however, only the valid synchronous tuples become executable since the exe- 
cutability of each rendezvous indication is evaluated at each reachable state of EFSMs. 
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3.3 Example of conversion to synchronous EFSMs 

After the algorithm Trans is applied to the main behavior expression of Switch in 
Sect. 2.1, seven SBEs are derived. We show part of them below: 

SBEn := label(Il): a?idt:IP; qilidt; goto(Il,— ) 

SBEoi := label(Ol): ( qo?odt:IP[l < dst(odt) < Nl]; a!odt; goto(01,— ) 

[] m?odt:IP[l < src(odt) < Nl]; goto(01,— ) 

[] m?odt:IP[not(I < src(odt) < Nl)]; alodt; goto(01 ,— ) ) 

SBEcrd := label(Crd): ( qi?data:IP[size(queue)<MAX]; goto(Crd,queue:=append(queue,data)) 

[] m!head(queue)[dst(head(queue))==0] ; goto(Crd,queue:=cdr(queue)) 

[] qo!head(queue)[dst(head(queue))!=0]; goto(Crd, queue :=cdr(queue)) ) 

In the above SBEs, process instantiations in the form of tail recursions are converted 
to the appropriate goto transitions. Each derived SBE can be converted to an EFSM 
easily. Fig. 2 depicts the resulting EFSMs and the multi-rendezvous table. Here, 
EFSMl - EFSM7 are converted from SBEn ~ SBEcrd, respectively. 

4 HARDWARE SYNTHESIS FROM SYNCHRONOUS EFSMS 

In this section, we give the technique to convert given synchronous EFSMs into a 
synchronous sequential circuit (our preliminary work can be found in [5]). Hereafter, 
we suppose the modules corresponding to EFSMs work synchronously with the same 
clock. In each clock cycle, each EFSM can execute a transition as long as its execution 
condition holds. We assume the components corresponding to ADT functions (e.g. 
guard expressions) are provided as combinational logic circuits and they can output the 
resulting values within a clock cycle. The circuit for each EFSM can be implemented 
easily by well-known techniques [9]. So, here we concentrate on the implementation 
of multi-rendezvous among EFSMs. 

Given EFSMs and a multi-rendezvous table, we implement multi-rendezvous among 
EFSMs as the multi-rendezvous circuit consisting of the following three sub-parts: (1) 
executability check part checking whether there exist executable synchronous tuples 
for each rendezvous indication at each state; (2) data transfer part transferring the re- 
quired data from a certain EFSM to the other EFSMs so that each EFSM can calculate 
the execution condition (guard) of its transition. (3) conflict avoidance part selecting 
a synchronous tuple among some mutually exclusive synchronous tuples; 

Hereafter, we suppose that synchronous EFSMs are given as {EFSM^TZ) where 
each rendezvous indication r £ TZ is represented as ((£?i, ...,Ey„), (Ai, ..., Am)) 
where each Ei £ EFSM. 

Constructing executability check and data transfer parts 

For the executability checking part, every EFSM in each rendezvous indication 
must check whether some transitions in its synchronous transition set are executable 
at the current state. So in each E^ for every r £TZ,wq provide a circuit generating an 
output signal rijok which becomes true (i.e. 1) only when a transition in Af becomes 
executable. Consequently, for the rendezvous indication r there exist some executable 
synchronous tuples if and only if ri^ok, ..., Vm^ok (denoted by r^jok) are true. 

For the data transfer part, EFSMs with input transitions and an EFSM with output 
transitions can be determined statically for each rendezvous indication by the criteria 
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Figure 4 An example of EFSMs. Figure 5 An example of derived 

circuit. 



in Sect. 2.2. Hence, we provide a path Dr among EFSMs for each r so that an EFSM 
outputs an appropriate value to the path and the others obtain the value. 

Constructing conflict avoidance part 

The conflict avoidance part generates the signal r xn which becomes true when r 
has the right to execute its synchronous tuple, avoiding conflicts between r and other 
exclusive rendezvous indications. Although there can be some policies for avoiding 
conflicts, we adopt a policy that gives a priority (or total order) among rendezvous 
indications and selects a rendezvous indication by the priority. 

Synchronous tuples of rendezvous indication r\ and V2 can conflict if and only 
if there exists the case that for a state set (si, • • • , Sp) of the common EFSMs in 
both rendezvous indications, the synchronous transition tuples of r i and V 2 are both 
executable at every state Sk{l < k < p). For all combinations of two rendezvous 
indications, we can statically determine whether they can conflict or not by checking 
the given EFSMs and the multi-rendezvous table. 

Any synchronous tuples of r cannot be executed when another conflicting ren- 
dezvous indication with priority higher than r is ready to execute a synchronous tuple. 
Consequently, we construct rjen as follows: 

r.en = ri.ok A - ' A Vm-ok A pri^ where pri^ = .en A • • • A -^r^.en 
(Here, {r\ • • • , r^} are the rendezvous indications with higher priorities than r which conflict 
with r. prir means whether r has the right to execute its synchronous tuple or not). 

Although we have introduced a priority based method, a module generating random 
numbers can also be used to select one of the conflicting rendezvous. 

An example of derived circuit 

In this section, we explain how we can derive the circuit in Fig. 5 from the syn- 
chronous EFSMs in Fig. 4 and the multi-rendezvous table in Table 3. 

Hereafter, we denote the output signal from EFSM j for the rendezvous indication 
Ti as rij -ok. At the initial state {si, si ), EFSMl first calculates the output value rn^ok 
for the rendezvous indication r\ as follows. As EFSMl’s current state is EFSMl 
calculates the execution condition p(a;i) V q{x2) for the transitions a?xi \p{xi)] and 
a?X2 [^(^ 2 )] which are transitions in its transition set and that of ri respectively. Fur- 
thermore, since p{xi) and q{x2) need external values to calculate the conditions. 
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Table 3 An example of multi-rendezvous table. 



Info. No. 


EFSMs 


synchronizing transition sets 


ri 


(EFSMl, EFSM2) 


({(a?xi,p(a:i),a:i •(- lorg{y)), 

{alx2,q{xi),X2 lorg{y)), (oTis)}, {(o!l,true, -)}) 


T2 


(EFSMl, EFSM2) 


{{{alxi,p{xi),xi i- 0), 

{alx2,q{x2),X2 ^0), (a?xs)}, {(a!0, frite, -)}) 


rs 


(EFSMl, EFSM2) 


{{(b\f {xi), true, -)},{{bly, true, y ^ f(xi))}) 



EFSMl uses the value from the data path Dri (the data path for the rendezvous indi- 
cation ri) for the values of xi and X2. So, it outputs the value of p{Dri) V q{Dri) 
to rn-ok. On the other hand, as EFSM2’s current state is 5i, EFSM2 can execute the 
transitions all in its transition set for the rendezvous indication r i . So it outputs true 
to r 12 jok. In addition, since all is an output transition, it outputs the value 1 to the 
data path Dri. For other rendezvous indications, EFSMs do the same operation. If 
rii^ok and r 21 -ok are both true, ri and r2 are conflict with each other because both 
r 12 -ok and V22-ok are also true. In this case, the conflict avoidance part selects r 1 and 
outputs true only to ri^en (since we assume that the priority ri > r 2 > rs holds). 

Finally, if r\..en is true, EFSMl executes either a?x\ or a?X2 depending on which 
condition inp(xi) and q{x2) holds (when the both conditions are true, EFSMl selects 
one of them by itself). If a?X 2 is executed, the value from Dri is assigned to X 2 . 
Further optimization 

Clock frequency is an important factor for efficient circuits. To what extent the 
frequency can go up depends on the critical path of the circuit, which is the most time 
consuming path of the logic gates used in a clock cycle. 

In our technique, for each rendezvous indication ri, (i) ri^ok and (ii) ri-en have 
to be evaluated in a clock cycle. The evaluation for (i) requires the transfer of data 
values among the related EFSMs and the evaluation of the guard expression in each 
EFSM. The evaluation for (ii) requires the logic gates of log h depth where h is the 
number of conflicting rendezvous indications. To shorten the critical path, we can 
take the following approach: (1) divide each complicated ADT function into several 
sub-modules with registers to calculate the result in several clock cycles based on the 
technique in [2]. (2) solve each conflict among multiple rendezvous indications in 
several clock cycles, for example, by dividing them into several groups. 

Another topic of the optimization is to reduce the number of data paths to sim- 
plify the resulting circuits. In general, several rendezvous indications can share a 
data path as long as they do not conflict with each other or cannot be executed at the 
same time. To share the data path, we allocate a bus available to the related EFSMs 
for some rendezvous indications. With this technique, all the required data path can 
be implemented by just N data buses where N is the maximum number of conflict- 
ing/simultaneous rendezvous indications. 

5 EXPERIMENTAL RESULTS AND DISCUSSION 

We have applied our technique to the LOTOS specification of Abracadabra proto- 
col [4] and constructed the hardware circuit to show that the constructed circuit is rea- 
sonably small and fast. We have used a hardware synthesis system PARTHENON [8] 
which has been developed by NTT. 
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In general, the modules for ADT functions (e.g. execution conditions) depend on 
how to implement the data types in the target circuit (e.g. the size of each data). 
Therefore, in this experiment, we have mainly evaluated the derived multi-rendezvous 
circuit without the modules for calculating ADT functions in each EFSM. 

The greatest effect in the performance will be the maximum depth of the logic 
gates in the circuit. Eight EFSMs were derived from the LOTOS specification of 
Abracadabra protocol using the algorithm in Sect. 3 (the derived synchronous EFSMs 
can be found in [5]). The number of rendezvous indications was 85, and the maximum 
number of the depth of the logic gates for the multi-rendezvous circuit was 7. The 
maximum depth became six after some optimization. 

Another criterion should be the size of the resulting circuit. The size of the multi- 
rendezvous circuit grows in proportion to the number of rendezvous indications since 
each rendezvous indication has its own module. The time for selecting a synchronous 
tuple set grows in proportion to the maximum number of rendezvous indications which 
may conflict with each other. In general, the number of the logic gates in the circuit 
depends on the size of data. 

We have synthesized the whole circuit with ADT data/functions using 8 bit data. 
We have used several hardware modules for implementing ADT functions such as 
integer comparison (e.g. =, <) and addition (e.g. inc, -f). 

In that case, the whole circuit obtained has about 5000 gates: about 500 gates for 
ADT functions; about 300 gates for the multi-rendezvous circuit; and the remainder 
for registers, selectors and control signals for EFSMs. 

The maximum depth of logic gates for ADT functions was 15. In the experiment, 
our technique requires additional 6 logic gates in depth for the multi-rendezvous cir- 
cuit. That means the whole circuit could work with the clock frequency at least 70 
% as high as in hardware circuits without multi-rendezvous. In fact, as we explained 
in the previous section, the multi-rendezvous circuit could be optimized further for 
practical use as well as other modules. We can approximately estimate the optimized 
performance from the circuit automatically derived with our technique. According to 
the above discussion, we think our technique can be used for rapid prototyping. 

6 CONCLUSION 

In this paper, we have proposed a hardware implementation technique from LOTOS 
specifications. In the technique, by composing each rendezvous indication of the tuple 
of event sets, we can keep the information about all possible rendezvous instances in 
a reasonable space. It is important that our conversion algorithm does not require any 
reachability analysis among parallel processes. Such analysis needs plenty of time 
proportional to the product of the number of events in parallel processes. Through 
the experiment for the Abracadabra protocol, we have confirmed our technique can be 
used for the rapid prototyping. We are going to evaluate our technique by implement- 
ing various protocols/systems, and possibly develop the optimization techniques for 
synthesized circuits for their practical use. To apply the technique to a time extension 
of LOTOS is part of future work. 
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Abstract: We present a discrete- time extension of Promela, a high level mod- 
elling language for the specification of concurrent systems, and the associated 
Spin model checker. Our implementation is fully compatible with Spin’s par- 
tial order reduction algorithm, which is indeed one of its main strengths. The 
real time package is for most part orthogonal to the other features of the tool, 
resulting in a modular extension. We have evaluated it by several experiments, 
with encouraging results. 

1 INTRODUCTION 

Promela is a high level modelling language for specification of concurrent sys- 
tems. The models written in Promela serve as input to the Spin software 
package for their automated verification. 

The time ordering of actions in a Promela program is implicit and depends 
on the (fixed) sequential composition of statements within each one of the 
component processes, as well as on the (unspecified) interleaving of statements 
from different processes. This time relation is only qualitative, meaning that we 
do not know the exact time interval that will elapse between two events. This 
can be a shortcoming when systems are to be verified whose correct functioning 
depends on timing parameters. Many such examples can be found among 
communication protocols that have to deal with unreliable transport media, 
where the duration of timeout intervals is important . 

In this paper, we introduce an extension to Promela that allows to quantify 
the time elapse between events, by specifying the time slice in which they occur. 
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We describe a prototype implementation that integrates this extension into the 
Spin tool. Of particular concern is the compatibility of such an extension 
with the partial order reduction algorithm, which is an approach to alleviate 
the state-space explosion inherent in model checking, and indeed one of Spin’s 
main strengths. We prove that Spin’s partial order algorithm remains correct 
under the new timing constructs, and conduct a number of experiments that 
demonstrate its effectiveness. 

The prototype implementation described in this paper grew out of an earlier 
implementation of discrete time in Promela and Spin [4] instigated by pro- 
cess algebra ACP [3] and clocked transition systems [15]. There, the timing 
constructs from the process algebra ACPdrt were modelled by macro defini- 
tions entirely on the level of Promela. An advantage of such an approach is 
that the real-time package thus obtained is orthogonal to Spin: when needed, 
it can be incorporated as a simple header-file inclusion, for the current and 
future versions of Spin. Furthermore, the resulting real-time extension is eas- 
ily moderated, allowing to gain experience with several alternative syntactical 
constructs and semantic models of time, and also to study the interaction with 
Spin’s other features, most notably its partial order reduction algorithm. An 
obvious drawback of such a ‘^high-level” solution is its inefficiency, which is to 
be avoided particularly in the case of a model checker. The real-time extension 
of Promela described in the current paper still uses macro definitions for cer- 
tain constructs. However, the operation that occurs most frequently, namely 
the advance of time (“tick”), has been implemented on a lower level, in the 
source code of the Spin tool. 

Eventually, we envisage a more complete integration of the real-time package 
into Spin, not only regarding the level of implementation, but the integration of 
real time and partial order reduction as well. Also, the underlying mathematical 
model will be changed from discrete to dense time. While this complicates the 
implementation, it is commonly accepted (c.f. [1]) that the resulting model- 
checking algorithms for dense time have comparable computational complexity. 
Having said this, we do stress that also discrete-time models are sufficient for 
a broad range of practical applications [11]. 

A closely related development is the RT-Spin package of [21]. Although that 
extension of Spin is more general in that it can model Timed Automata ([!]), 
with real-valued clocks, it has a number of drawbacks. The most important 
one is that it is not compatible with the partial order reduction algorithm. 
Furthermore, Timed Automata lack a notion of urgency; instead, the fact that 
a transition with a deadline must be taken on time, has to be modelled explicitly 
in RT-Spin. Also, the package has not been kept up-to-date with Spin versions 
later than Version 2.0. 

The extension of partial order reduction techniques to apply to real-time 
systems has recently been studied in [18] and [17]. Other model checkers that 
cover timed behaviour are, e.g., UPPAAL ([14]), COSPAN ([2]), and HyTech ( 
[10]). The latter indeed is able to handle the more general class of linear hybrid 
systems. 
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2 THE SPIN MODEL CHECKER 

Promela and Spin have been developed for the analysis and verification of 
communication protocols. The language syntax is derived from C, but also 
uses the denotations for communications from Hoare’s CSP and control flow 
statements based on Dijkstra’s guarded commands. The full presentation of 
Promela and Spin is beyond the scope of this paper. We suggest [12] as a 
reference to the interested reader; here, we only give a brief overview of Spin’s 
verification capabilities. 

In Promela, system components are modeled as processes that can commu- 
nicate via channels either by buffered message exchanges or rendez-vous oper- 
ations, and also through shared memory represented as global variables. The 
execution of statements is asynchronous and interleaved, which means that in 
every step only one enabled action is performed, without any assumptions of 
the relative speed of process executions. 

Given as input a Promela model. Spin generates a C program that performs 
a verification of the system by scanning the state space using a depth-first 
search (DFS) algorithm. This way, both safety properties such as absence 
of deadlock, unspecified message receptions, invalid end states and assertions 
can be checked, as well as liveness properties such as non-progress cycles and 
eventual reception of messages. The so-called never claims, which are best seen 
as monitoring processes that run in lock step with the rest of the system, are the 
most general way to express properties in Spin. Being Biichi Automata, they 
can express arbitrary omega-regular properties. Spin provides an automatic 
translator from formulae in linear-time temporal logic (LTL) to never claims. 
When errors are reported, the trace of actions leading to an invalid state or 
cycle is saved, so that the erroneous sequence can be replayed as a guided 
simulation. 

For large state spaces methods. Spin features state- vector compressing, partial- 
order reduction and bit-state hashing. 

2.1 Partial order reduction 

Partial order reduction (POR) is a technique to cope with the state explosion 
problem in model-checking. We give a brief introduction to the POR algorithm 
that is used in Spin, rephrasing some definitions from [13]. 

The basic idea of the reduction is to restrict the part of the state space that is 
explored by the DFS, in such a way that the properties of interest are preserved. 
To this purpose, the independence of the checked property from the possible 
interleavings of statements is exploited. More specifically, two statements a, 6 
are allowed to be permuted precisely then, if for all sequences v,w of statements: 
if vabw (where juxtaposition denotes concatenation) is an accepted behaviour, 
then vbaw is an accepted behaviour as well. In practice, sufficient conditions 
for such permutability are used that can be checked locally, i.e., in a state. For 
this, a notion of ‘‘concurrency” of statements is used that captures the idea 
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that transitions are contributed by different, concurrently executing processes 
of the system. 

The semantics of a Promela program can be represented as a labeled transi- 
tion system (LTS). An LTS is a triple (S', 5 q, T), where S is a finite set of states. 
So is a distinguished initial state, and T C S x S is a set of transitions. Every 
transition in T is the result of executing a statement in some process of the 
Promela program. We introduce a function Label that maps each transition to 
the corresponding statement. For a statement a, Pid{a) denotes the process 
to which a belongs and En{a) denotes the set of (global) states in which a is 
enabled. For q G E'n(a), a{q) is state which is reached by executing a in state 

Concurrent statements (i.e. statements with different Pids) may still influ- 
ence each other’s enabledness, whence it may not be correct to only consider one 
particular order of execution from some state. The following notion of indepen- 
dence defines the absence of such mutual influence. Intuitively, two statements 
are independent if in every state where they are both enabled, they cannot dis- 
able each other, and are commutative, i.e., the order of their execution makes 
no difference to the resulting state. 

Definition 2.1.1 The statements a and b are independent iff for all states q 
such that q 6 En{a) and q G En{b), 

■ o>{q) G En{b) and b{q) G En{a), and 

■ a{b{q)) = b{a(q)). 

Statements that are not independent are called dependent. 

Note that a and b are trivially independent if En{a) Pi En{b) = 0. An example 
of independent statements are assignments to or readings from local variables, 
executed by two distinct processes. 

Another reason why it may not be correct to only consider only one particular 
order of execution from state s of two concurrent statements a and 6 is that the 
difference between the intermediate states a{s) and b{s) may be observable in 
the sense that it influences the property to be checked. For a given proposition p 
that occurs in the property (an LTL formula), and a state s, let p(s) denote the 
boolean value of the proposition p in the state s. Then, a is invisible iff for all 
propositions p in the property and all states s G En{a), we have p{s) = p{a{s)). 
a is said to be safe if it is invisible and independent from any other statement 
b for which Pid{b) ^ Pid{a). 

The reduction of the search space is now effected during the DFS, by limiting 
the search from a state s to a subset of the statements that are enabled in 5, the 
so-called ample set. Such an ample set is formed in the following way: If there 
is a process which has only safe statements enabled and all those transitions 
lead to a state which is not on the DFS stack, then the ample set consists of 
all the statements from this process only. Otherwise, the ample set consists of 
all enabled statements in s. It can be proven [13, 19] that the reduced graph 
obtained in this way preserves the properties of the original LTS, stated as an 
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LTL formula. The condition that all transitions from the ample set must end 
out of the DFS stack, the so-called ‘‘cycle proviso”, ensures that a statement 
that it is constantly enabled, cannot be “forgotten” by leaving it outside the 
ample set in a cycle of transitions. 

While the cycle proviso is clearly locally checkable during a DFS, the condi- 
tion that an enabled statement is safe is not, as the definition of safety requires 
independence from any concurrent statement. A sufficient condition for safety 
of a statement a that can be checked locally is that a does not touch any global 
variables or channels. Indeed, it is this condition that is implemented in Spin. 

3 INTRODUCING DISCRETE TIME IN PROMELA AND SPIN 

3.1 Real time Promela 

In the discrete time model, time is divided into slices indexed by natural num- 
bers. The actions are then framed into those slices, obtaining in that way 
a measure for the elapsed time between events belonging to different slices. 
Within a slice however, we only know the relative ordering between events, as 
in the time free case. The elapsed time between events is measured in ticks of 
a global digital clock that is increased by one with every such tick. 

In state space enumeration methods like the one used in Spin, verification can 
be regarded as checking all possible simulations of the system. In that sense the 
simulation can be considered as a primitive for the validation, so we start with 
the description of the discrete time implementation for simulation purposes. 
The basic idea is to execute the system time slice by time slice. Recalling that 
the execution of statements in Spin is asynchronous and interleaved, the basic 
problem is how to avoid interleaving of actions belonging to different time slices. 
One way to solve this is by forcing each process to stop the execution after it 
has executed all the actions for the current time slice, waiting to receive a signal 
that the system has passed to a new time slice. This synchronization is done by 
a special “daemon” process that is not a part of the modelled system and waits 
in the background to become active only when all the other processes from 
the system are blocked. This daemon process is a pacemaker that transfers 
the system to the next time slice, by sending unblocking signals to the other 
processes. 

We implement this synchronization scheme by extending Promela with a new 
variable type timer corresponding to discrete time countdown timers, three 
new statements set, expire and tick that operate on the new type, and a 
special timing process Timers which is the daemon process that uses ticks to 
decrease the timer values. The implementation can be done entirely on user 
level, without any additional changes in the Spin source code, for example, with 
the following Promela macro definitions and timer process: 

#define timer int 

#define set(tmr,val) (tmr=val) 

#define expire (tmr) (tmr==0) /*timeout*/ 

#def ine tick (tmr) if : : tmr>=0 -> tmr=tmr-l : : else f i 
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proctype Timers () 

{ do : : timeout -> atomic{ tick(tmrl); tick(tmr2) } od } 

The first macro defines timer as a synonym for the integer type The set 
macro sets the value of the timer tmr to val. The expire macro is a test 
which becomes true when tmr becomes 0. The tick macro is used only in the 
Timers process and it decreases the value of tmr provided that it is active, 
i,e., its value is non-negative. Timers with negative values are considered as 
deactivated. Timers consists of an endless do iteration that realizes the passage 
of time. It is run concurrently with the other processes of the system. The key 
idea of the concept is the usage of timeout - a predefined Promela statement 
that becomes true when no other statement within the system is executable. 
By guarding ticks with timeout, we ensure that no process will proceed with 
an action from the next time slice until the other processes have executed all 
actions from the current time slice^ . 

Within a process, statements are divided into time slices by putting set and 
expire at the beginning and end, respectively, of each time slice. For instance, 
assuming that we have declared timer tmr, and that A, B and C are nonblocking 
Promela statements, the sequence 

set (tmr, 1); A; B; expire (tmr); C 

means that A and B will be executed in same time slice, while C belongs to 
the next time slice. The expire statement is a synchronization point where 
the process waits for tmr to become zero. This can be done only by Timers, 
i.e., only when all active timers are decreased. Thus, it is guaranteed that C 
will be executed in the next time slice. In fact, set is only a labelling of the 
time slice (some sort of reading of the global digital clock we assumed in our 
time model) and it can be permuted with the statements from the time slice 
that it labels (in our case A and B). 

Also, in cases where we have empty time slices, we optimize sequences of the 
form 

set(tmr,l) ; exp ire(tmr ); set (tmr, 1) ; expire (tmr) ; . . . ;set(tmr,l) ;expire(tmr) ; 

by set (tmr, val) ; expire(tmr); , where val is the number of set-expire 
pairs. 

It is often convenient to use derived macros for modeling various delays. 
For instance, one tick delay and unbounded nondeterministic delay are imple- 
mented, by the following macros 

#define del ay (tmr, val) set (tmr , val) ; expire (tmr) 
tdefine udelay(tmr) do :: delay (tmr, 1) :: break od 

In the unbounded nondeterministic delay, at each iteration a nondeterminis- 
tic choice is made whether the loop will be broken and the process will proceed 



^ There is one tick for each timer in the system, In the example above we assmned that there 
are only two timers, tmrl and tmr 2. The ticks are wrapped in atomic statement in order to 
avoid unwanted unblocking of some of the system processes before edl timers are decreased. 
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with the execution of a new statement, or the decision will be delayed for the 
next time slice. In a similar way a nondeterministic bounded delay up to a 
certain number of ticks, or a nondeterministic delay within lower and upper 
bounds can be modeled. 

The expressiveness of our extended Promela is the same as the one of timed 
automata interpreted in integral time (fictitious clocks, using the terminology of 
[1]). It is straightforward to show that using the aforementioned derived timing 
constructs one can model timed automata interpreted in integral time. Con- 
versely, following the approach of [21], the semantics of the extended Promela 
can be given via timed automata. 

It is noteworthy that, because of the independence of the timing implemen- 
tation from the other parts of the Spin’s source code, the expressivity of the 
timing framework is in fact augmented with the introduction of new features 
in Spin. For instance, a scheduler for several processes running on a single 
processor can be modeled in a natural way like an additional master process 
that synchronizes the other processes by giving them execution permission via 
Promela’s provided declarator mechanism, which was recently introduced into 
Spin (from version 3.0). 

3.2 Example 

In this section we show how the discrete time can be used for the specification 
and verification of the Parallel Acknowledgment with Retransmission (PAR) 
protocol [20] . The choice of PAR was motivated by the fact that it is a relatively 
simple protocol, yet it is complex enough that its correct functioning depends 
on the duration of time intervals in a nontrivial way. PAR has been used in 
similar studies as this one, cf. [22, 16]. 

PAR is one-way (simplex) data-link level protocol intended to be used over 
unreliable transmission channels which may corrupt or lose data. There are 
four components in our implementation: a sender, a receiver, data channel K 
and acknowledgment channel L. The sender receives data from the upper level 
and sends them labeled with a sequence number that alternates between 0 and 
1 over the channel K. After that it waits for an acknowledgment via the channel 
L. If this does not occur after some period of time, the sender times out and 
resends the old data. If the data are received undamaged and labelled with the 
expected sequence number, the receiver delivers them to the upper level and 
sends an acknowledgment. 

Of crucial importance here is the duration of the time-out period which 
should be longer than the sum of the delays through the channels and the 
message processing time by the receiver. A premature timeout can cause the 
loss of a frame by the following scenario: The sender sends a frame and times 
out too early. This causes a duplicate of the just sent frame to be sent too. The 
receiver receives both frames and sends two acknowledgments. When the sender 
gets the acknowledgment for the first frame it thinks that it is for the second one 
(the duplicate). After receiving this first acknowledgment it sends next frame, 
which is lost by the data channel. In the meantime the second acknowledgment 
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arrives (which was sent by the receiver as a result of successful receiving of the 
duplicate) and the sender mistakenly thinks that it is an acknowledgment for 
the last frame and never resends it. 

The complete listing of the discrete time Promela model of PAR is given on 
the next page. 

The Promela model starts with the already described preamble of macros 
for discrete time. 

Then, after the definition of protocol specific parameters, the timers are 
declared. There is one timer per protocol entity, i.e., for sender (sc), receiver 
(rc), channel K (xk) and channel L (xl). Although used locally in this model, 
the timers are declared on global level in order to be accessible for Timers. The 
four defined Promela channels A, B, C and D have capacity 0 meaning that they 
are synchronous rendez-vous channels. A, B, C and D are used only as auxiliary 
channels, because the “real” unreliable channels are modeled as proctypes, 
i.e. as a separate processes. The channels A and B are the input and output, 
respectively, to the channel K. 

They deal with messages consisting of two fields — one of type byte and 
one of type bit, corresponding to the message contents and the alternating bit. 
Similarly, C and D are the input and output for L and they can carry messages 
containing just one bit — the acknowledgment. 

After the declarations of local variables, the Sender process begins with 
an unbounded start delay of the first operation which fetches a message from 
the upper level (user). In our model this is simplified by allowing Sender to 
generate the message itself by the statement mt = (mt+l)*/,MAX. The message 
followed by a sequence number is sent through the channel K. This event is “la- 
beled” by an activation of the timer sc which is needed for the usual timeout 
mechanism (not to be confused with the timeout Promela statement) for un- 
blocking the protocol in case of message or acknowledgment loss. After sending 
the message the Sender blocks waiting for the arrival of an acknowledgment or 
the expiration of the timeout timer. In the first case a nondeterministic choice 
^ is made between signalling an error because of a corrupted acknowledgment 
and accepting the acknowledgment as correct. 

Receiver starts by waiting for a message. This is achieved by the statement 
B?mr,sn, which denotes the reception of a message through the channel B. The 
receiving statements in our implementation are treated as executable as soon 
as possible, i.e. in the same slice when the corresponding sender is ready to 
send. After the label S_h an assert is used to ensure that the received message 
always matches the expected one. (Note that this statement is added to the 
model only because of validation reasons.) The message processing latency is 
modeled by a delay on the Receiver’s timer. Also the expected message and 
sequence number are updated. Successful reception is confirmed by sending 



^The if statement is similar by its semantics to the do statement - a random choice is made 
between the alternatives and if none of them is enabled than the statement is blocked. 
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/♦discrete time macros*/ 



/♦clianiiel processes*/ 



Ideline timer iat 
tdelime set(x,y) x*y 
Idelime expire (x) (x==0) 

Ideiiae tick(x) il :: x>=0->x=x-l ; :: else; ii 
fdeiiae oa(x) (x!*-!) 



Ideiiae delay(x.y) set(x,y); expire(x); 

ideiiae adelay(x) do :: delay(x.l) :: break od 

/♦PAR time parameters*/ 

Ideiiae dK 3 /* delay aloag chaaael R */ 

Ideiiae dL 3 /* delay aloag ckaaael L */ 

Ideiiae dR 1 /* receiver’s message processiag time */ 
Ideiiae To 9 /* seader’s time oat valae */ 

Ideiiae HAX 8 /*max aamber oi diiiereat message coateats*/ 

/♦timers*/ 

timer sc, rc , xk, xl; 

pro c type Timers () 

{ 

do 

: : time oat -> 

atomic{tick(sc) ; tick(xk); 

tick(rc); tick(xl);} 
od; 



/♦chaaaels*/ 

chaa A = [0] oi {byte, bit}; 
chaa B = [0] oi {byte, bit}; 
chaa C = [0] oi {bit}; 
chaa D = [0] oi {bit}; 

/♦protocol eatities*/ 

proctype SeaderO 

{ 

byte mt; /* message data */ 
bit sa=0; /* seqaeace aamber*/ 

R_h: 

/♦message caa be seat ia aay time slice*/ 
adelay(sc) ; 
mt = (mt+l)XHAX; 

S_i: 

A!mt,sa; /*saad throagh chaaael K*/ 
set(sc ,To) ; 

¥_s: 

do 

D?_ -> 
it 

atomic{skip; delay(sc, 1); saal-sa; goto R_h;}; 
:: atomic{priati ("HSC : ACRerr\a") ; goto S_i}; 
ii; 

expire(sc) -> goto S_i ; /*timeoat*/ 
od; 



proctype K() 

{ 

byte rd; /*received chaak*/ 

bit rab; /*received aad expected bits*/ 

do 

:: A?rd,rab; 

delay(xk, dX) ; 
ii 

skip; Bird, rab: 

: skip ; 

ii; 

od; 

} 

proctype L() 

{ 

do 

:: C?_; 

delay(xl,dl); 

ii 

: skip ; D! 1 ; 

: skip ; 

ii; 

od; 

} 

iait 

{ atomic{set(sc ,-l) ; set(rc,-l); 

set(xk.-l); set(xl,-l); 

raa TimersO; 

raa SeaderO; 

raa R ( ) ; 

raa L( ) ; 

raa RcceiverO ;} 



} 

proctype ReceiverO 

{ 



byte mr, me=l ; /* received aad expexted message*/ 

bit rsa, esasQ; /*received aad expected seqaeace aamber*/ 

W_i: 

B?mr ,rSB; 
ii 

:: rsa == esa -> goto S_h; /*correct message aa^^ seq. aam */ 

:: rsa == l-esa -> goto S_a; /*correct message, aroag seq. aam */ 
atomic{priati("HSC: HSGerrVa") ; 

goto V_f;}; 
ii: 

S.h: 

/♦Oat !mr*/ 
as8ert(mr == me) ; 
atomic{delay(rc ,dR) ; 

/♦message processiag delay*/ 
esa = l-esa; me = (me+l)XHAX}; 

S_a: 

C!l; /*sead ack throagh chaaael L*/ 
atoaic{delay(rc , 1); goto V_i;}; 
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a message through L (via Promela channel C) and after a latency delay the 
Receiver starts waiting again to a new message. 

Channel processes model the lossy channels K and L. Both processes have 
the same structure — after a delay they nondeterministically chose between 
delivering or losing the message. The skip is always executable. It is used here 
to give equal precedence for both choices. 

All processes are started from a special process called init via run state- 
ments. By enclosing the run statements within an atomic it is ensured that 
they start simultaneously. 

Verification of the model can be done like in the standard Spin. Among the 
other properties, the validator is able to find out and display the scenario of 
losing a message, in case of an erroneous combination of the timing parameters. 

3.3 Low level implementation 

In order to achieve more efficiency we get down from the high-level implementa- 
tion to a lower level, by realizing the tick construct in the Spin’s source code. 
Also, the new semantics of tick is adopted so as to decrease all the timers 
in the system together. The implementation of the new statement in Spin is 
completely modular and does not interfere with other features. 

The timing procedure now becomes much simpler: 

proctype Timers 
{ do : : timeout -> tick od } 

As it is universal for all models, it can be made part of the standard header 
file that contains the basic macros. Another advantage of the new tick is that 
the timers can be declared locally. Like ordinary local variables, local timers 
can be dynamically created and deleted together with the processes they belong 
to. To the best of our knowledge this possibility is not present in any tool for 
validation of timed systems. Variable number of timers automatically means 
saving of the state space, due to Spin’s variable size state representation. 

The most important benefit of the local usage of timers is the partial order 
reduction which is, as already emphasized, one of the main strengths of the 
enumerative methods. The integration of partial order reduction with the dis- 
crete time model is one of the main results of this paper and it is the topic of 
the next subsection. 

3.4 Compatibility with partial order reduction 

In this section we prove that the partial order reduction algorithm of (standard, 
untimed) Spin is correct for the timed extension as well. This algorithm is based 
on selecting, during the DFS exploration of the state space, only statements 
from the ample set. The construction of an ample set is based on the notion 
of safety of statements: given a criterion to determine which statements are 
safe, the underlying theory, that was presented in Section 2.1, guarantees that 
the reduction strategy is correct, i.e. that (LTL) properties are preserved. For 
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untimed Spin, this criterion is that a statement does not read or write any global 
variables or channels. We will now show that this criterion is still sufficient in 
the presence of timed statements. 

Lemma 3.4.1 Any statement that is safe in standard, untimed Promela, re- 
mains safe in the presence of the new timed statements set, expire, and tick. 
Furthermore, when applied to locaP timers, the statements set and expire are 
safe, and tick is independent from any other statement. 

Proof In order to show that a statement is safe, we have to show that it is invisible, 
and independent from any concurrent statement (i.e. any statement with a different 
Pid). 

Let a be a statement in untimed Promela that is safe. Then it is clearly still 
invisible in timed Promela. Also, a is obviously still independent from any concurrent 
untimed statement, a’s independence from any (“new”) timed statement that is 
concurrent follows from the fact that the set of timer variables, that are the only 
variables which can be read or written by timed statements, is disjoint from the set 
of ordinary variables which can be affected by a. 

Next, we let a be one of the statements set and expire, applied to a local timer. 
a is invisible because the local timer variable may not occur in the property to be 
checked. Let 6 be a concurrent statement different from tick. Then a is obviously 
independent from h because of the disjoint sets of variables they operate on. Indepen- 
dence between tick and a, and indeed independence between tick and any timed or 
untimed statement, follows from the fact that tick can never be enabled simultane- 
ously with another statement. This is because of the way tick is implemented: it is 
only enabled in the case of a timeout condition. 

As tick is implemented in the Spin source code, is is not subject to reduction 
by the partial order algorithm. However, this does not have any repercussions: 
any tick statement, regardless whether it is acting on a local or on a global 
timer, is the only statement that is enabled, when it is enabled at all. So, no 
reduction would have been possible anyway. 

4 EXPERIMENTAL RESULTS 

We have tested the implementation on various models known in the literature 
(e.g. Train Gate Controller, Seitz Circuit, Leader Election Protocol). We focus 
our attention on three of them that illustrate the effectiveness of the implemen- 
tation and particularly the partial order reduction: Fischer’s mutual exclusion 
protocol, the already presented PAR protocol and the Bounded Retransmission 
Protocol (BRP). All tests were performed on a Sun SPARC Station 5 with 64 
MBytes of memory. Besides partial order reduction we used as an additional 
option minimized automata, a technique for reduction of the state space re- 
cently included in the standard Spin distribution. In the options column of the 



^Recall that a local timer is a timer variable that is declared local to a Promela process. In 
timed Spin, it can be manipulated by the declaring process or by the tick operation. 
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tables below, “n” , “r” and “ma” denote verifications without POR, with POR, 
and with POR together with minimized automata, respectively. 

The version of the Fischer’s protocol that was verified is a translation of the 
same model written in Promela with real (dense) time of [21], with virtually the 
same timing parameters. The obtained results for the verification of the mutual 
exclusion property are shown in Table 1 (N is the number of processes). As 



Table 1 Results for Fischer’s and PAR protocol. 



m 




states 


transitions 


memory [MB] 


time [s] 




n 




876 


1.453 




r 


378 


490 


1.453 


0.1 


ma 


378 


490 


0.342 


0.2 


3 


n 


8425 


10536 


1.761 


0.8 


r 


3813 


4951 


1.596 


0.4 


ma 


3813 


4951 


0.445 


0.3 


4 


n 


128286 


373968 


7.085 


15.5 


r 


34157 


44406 


3.132 


2.8 


ma 


34157 


44406 


0.650 


33.7 


5 


r 


288313 


377032 


17.570 


36.2 


ma 


288313 


377032 


1.059 


332.5 


6 


ma 


2.35e6 


3.09e6 


2.118 


6246.1 



time parameters 


option 


states 


transit. 


mem. [MB] 


time [s] 


dK 


dL 


dR 


To 


3 


3 


1 


9 


n 


1318 


1822 


1.453 


0.2 


r 


1116 


1533 


1.493 


0.3 


30 


30 


10 


90 


n 


7447 


9994 


1.761 


0.5 


r 


7295 


9705 


1.801 


0.6 


300 


300 


100 


900 


n 


68737 


91714 


5.135 


4.9 


r 


68585 


91425 


5.420 


4.9 


ma 


68585 


91425 


2.221 


143.7 



expected, the state space growth is exponential and we were able to validate the 
model without using POR up to 4 processes. For 6 processes even POR was not 
enough and it had to be strengthened with minimized automata. Nevertheless, 
the profit from POR is obvious and even becomes more evident as the number 
of processes grows. While for A = 2 the number of states is reduced to 72% 
compared to the case without POR, and the transitions are reduced to 56%, 
foT N = 4 the reduction increases to 27% and 12% for states and transitions, 
respectively. 

It is difficult to compare our implementation with the one from [21], be- 
cause they are based on different time models. Nevertheless, having in mind 
that the property that was checked was a qualitative one, for which discrete 
time suffices [11], one can safely say that after A = 4 our implementation 
has better performance. In fact, for iV = 5 the validator from [21] runs out 
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Table 2 Results for timed and untimed BRP. 



option 


states 


transitions 


memory [MB] 


time [s] 


n 


32967 


71444 


4.116 


6.7 


r 


12742 


14105 


2.517 


3.2 


ma 


12742 


14105 


1.571 


26.4 



option 


states 


transitions 


memory [MB] 


time [s] 


n 


199454 


658852 


7.515 


37.6 


r 


113566 


294546 


5.547 


19.0 



of memory. Obviously, POR is the decisive factor, because without POR our 
implementation is also incapable to handle cases for > 4. 

In the case of the PAR protocol the reduction is very small and even dimin- 
ishes with the increase of parameters (Table 1). The insensitivity of PAR model 
to reduction can be explained by observing that PAR is in fact a sequential al- 
gorithm. The protocol entities take turns during the execution of the protocol, 
most of the time only one of them being active while the others are waiting 
passively for some trigger-event. Very little concurrent activity results in a 
bad behaviour of the POR algorithm which deals with concurrent actions from 
different processes. It is an opposite situation compared to Fischer’s protocol 
where the higher degree of concurrency led to an improvement of the effects of 
POR. 

Note the sensitivity of the state space to the increase of parameter values. 
This sensitivity to parameters is analogous to the same effect observed in the 
region automaton implementation of the dense time system based on timed 
automata [1, 2]. At least for the type of protocols like PAR, when the sequen- 
tial component of the system is predominant, this problem can be solved by 
grouping together consecutive ticks into one tick to avoid generation of spurious 
intermediate states. 

Our implementation of BRP is based on [6], where the protocol was treated 
using a combination of Uppaal (for timing aspects) and Spin (for consistency of 
the specification). We give the results for safety properties (absence of deadlock 
and assertions). Using the same parameters as in [6], all the properties verified 
there can be checked with a memory consumption of at most 5 Mbytes and less 
than a minute of CPU time. This is a much better result than the one in [6]. In 
addition, our model has the advantage that the validation is done completely 
within Spin. 

The benefit of POR reduction is obvious — the number of states is reduced to 
39%, while the transitions are reduced to 20%. In order to get an indication how 
well the partial order reduction combines with our time extension in Spin, we 
have compared the above reductions for the BRP to the partial order reduction 
that is achieved on a slightly different version of the protocol that does not 
involve timers (see e.g. [8] or [7]). The result is given in Table 2. The effect for 
the timed version turns out to be even better: 39% and 20% versus 57% and 
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45%. It has to be said though that in order to model the effect of timeouts in the 
untimed case, we need an additional global variable, which may influence the 
effects of the reduction. Anyway, this is a promising result having in mind that, 
unlike previous two examples which are more academic, BRP is just slightly 
simplified version of an industry protocol used by Philips, which gives us hope 
that POR could work for real-world applications. 

5 CONCLUSIONS AND FUTURE WORK 

We presented an extension of Promela and Spin with discrete time, using in- 
teger variables as timers to stamp the time slices. The core idea was to use a 
special background daemon process to implement the passage of time. For this 
purpose we used the Promela timeout predefined statement as a mechanism for 
process (i.e. timer) synchronization. We first showed how the concepts can be 
implemented using only the existing features of Promela and Spin, by extend- 
ing the language with new time statements as Promela macro definitions. The 
usage of timing features was demonstrated on the specification and validation 
of the PAR protocol. 

As one step further toward a more efficient integration of the timing frame- 
work into Spin, we implemented timing on the level of the validator’s source 
code. With this low level implementation, we gain the possibility to use the 
timers locally. This allows for dynamic change of the number of timers in the 
system — a feature which to the best of the authors’ knowledge does not exist 
in any implementation of verification of real-time systems. This is in accord 
with the possibility of dynamic creation of processes already present in Spin. 
But, the most important benefit of the local usage of timers, and one of the 
main results of this paper, was the adaptation of the existing partial order 
reduction algorithm to the discrete time setting. The urgency that is a neces- 
sary feature in the modeling of a broad class of interesting timing dependent 
systems is achieved in a natural way, without usage of invariants. The low 
level implementation is a seamless and completely compatible extension of the 
standard Spin validator which allows one to use all the existing features of the 
untimed validator in a standard way. We showed the efficiency of the partial or- 
der reduction and the implementation in general on several examples, of which 
we emphasize the verification of the Bounded Retransmission Protocol, as an 
industrial protocol used by Philips. The main future tasks will certainly be 
to test the approach and accumulate experience by doing new verifications on 
systems known in the literature or some new real-world (industry) cases which 
are time dependent. 

Besides the improvement of the existing prototype, the main direction for 
the future work will be the extension of Promela and Spin with dense time, 
which will provide the possibility to express and verify a more general class of 
properties. The full description of the implementation will be presented in a 
forthcoming paper. Here we give an outline of the basic idea, assuming that 
the reader is familiar with the theory of timed automata (see for instance [1]). 
In the dense-time extension we consider each Promela process in the system 
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as a timed automaton, thus, the system as a whole is then represented as a 
parallel composition of timed automata. For this purpose we have to extend 
Promela with a new variable type clock whose value can be tested (compared) 
and/or set to zero. We are going to implement the discretizations of the timed 
automata, called region automata. Once we have these discretizations we can 
reuse the same basic concepts from the discrete-time implementation presented 
in this paper. The key idea is that to represent the time passage for the 
dense time one can again use a discrete global clock which ranges over clock 
regions (instead over integer valued vectors, as it was for the discrete time). 
The number of regions is always finite [1] which guarantees termination of the 
validation procedure. Thus, the whole concept of a special procedure that 
implements the time passage can be applied, like for the discrete-time case. 
Although there are many technical details that we omit because of the space 
limitations, it is obvious that the same concept of timeout as a clock tick can 
be also reused to obtain an extension which can be easily integrated with the 
other features of Spin. With regard to the efficiency it is promising that the 
partial order reduction algorithm can be adapted in the same way as for discrete 
time. 

It would be very interesting to incorporate the ideas about data and time 
abstraction of [5] both in the existing discrete time prototype, as well as in 
the future dense time implementation, in order to obtain verifications that are 
independent of the concrete parameter values, and to see how general is their 
applicability. 

Another promising idea is to extend the concept of time managing process to 
a class of hybrid systems called discrete time rectangular automata [9]. This can 
be done by introducing, besides timers (clocks), new time dependent variables 
and allowing the timing process to change their value also with steps greater 
than one. 
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Abstract: In this paper we present a tool (CMC) for compositional model- 

checking of real-time systems. CMC is based on a completely different method 
compared to existing real-time verification tools (HYTECH, KRONOS, UP- 
PA AL). After a description of the method, we illustrate its efficiency by con- 
sidering two examples : the Fischer’s mutual exclusion protocol and a railroad 
crossing system. 

INTRODUCTION 

Within the last decade, model-checking has turned out to be a useful and 
successful technique for the verification of temporal properties in finite state 
systems. More recently, serious attempts have been made to extend the success 
of model-checking to the setting of real-time systems, with timed automata [2] 
as models. The major obstacle for the model-checking approach is the well- 
known state explosion problem due to parallel composition (as in the untimed 
case) and also to time encoding. Several heuristics have been proposed to over- 
come this problem : symbolic model-checking [10], on-the-fly technique [6, 19], 
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efficient data-structures for time constraints [17, 4]. These and other tech- 
niques have been implemented into tools (KRONOS [22], UPPAAL [19] and 
HYTECH [11]) and a number of industrial case studies have been analyzed and 
verified using these tools [12, 13, 5, 20, 9]. 

In [16] we proposed a first compositionaimodei-checAdng technique, which in 
a number of practical examples seems to avoid the state explosion problem. In 
this method, we never construct nor examine the global (symbolic) state space 
of a real-time system modeled as a network (Ai| . . .|An) of timed automata. 
Rather, when checking the system for a property y?, the components Ai , . . . , 
are gradually removed from the network and incorporated into the formula; 
thus, the component An could be initially transfered from the network into the 
property (f yielding a new quotient property (p/An which expresses the precise 
property which has to be satisfied by the remaining network (Ai| . . . |A„_i) 
in order that the original property p holds for the complete system. Now by 
repeatedly quotienting components from the network into the formula, we will 
finally be faced with the problem of establishing that the process nil (a process 
capable of performing no action at all) satisfies the last formula. A key point 
of this approach is to develop efficient simplification strategies in order to keep 
a small size of the quotiented formula. 

In this paper we extend the compositional method in several ways. Firstly, 
we develop the method to a larger class of timed automata (with invariants and 
atomic propositions). Secondly we introduce a completely new (and consider- 
ably more efficient) quotient construction and specific simplification techniques 
adapted to our formalisms. Finally we present CMC a new real-time verification 
tool implementing the compositional method. 

Plan of the paper: we first introduce the formalisms used in CMC : networks 
of timed automata used for the modeling of real-time systems, and the timed 
modal logic for specifying properties. We then present the quotient construc- 
tion together with the simplification strategies emphasizing those dealing with 
clock constraints. Finally we illustrate the method with two examples. The 
first example is Fischer’s mutual exclusion protocol [1, 21], which is a classical 
benchmark in this domain. Here our results both demonstrate the efficiency as 
well as the limits of the compositional approach. The second example is the 
railroad crossing system. In this example, proves to be an extremely conve- 
nient specification language, and our results proves that compositional method 
is useful for arbitrary systems and not only for networks with a symmetrical 
structure as in Fischer’s protocol. 

NETWORKS OF TIMED AUTOMATA 

Let ^ be a finite set of actions and AP a finite set of atomic propositions. We 
denote by N the set of natural numbers and by R the set of non-negative real 
numbers. 0 denotes the set of delay actions {e(d) \ d G R}. If C is a set of 
clocks, B{C) denotes clocks constraints over C, that is the set of formulas built 
using boolean connectives over atomic formulas of the form xxmorx — yixm 
with X, p E C, m E N and txE {=?<)>,<,>}• Moreover B~(C) denotes the 
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Figure 1.1 The Fischer’s mutual exclusion protocol modeled with timed automata 



restriction of B[C) to the boolean value true and to the conjunctions of atomic 
formulas of the form a: ixi m with x ^ C and cxG {<,<}• A time assignment v 
for C is a function from C to R. We denote by the set of time assignments 
for (7. For v G R^ and d eK, v + d denotes the time assignment which maps 
each clock a? in C to the value i^(x) + d. For C C C, [C 0]v denotes the 
assignment for C which maps each clock in (7' to the value 0 and agrees with v 
over C\C . Whenever v G R^, u G R^ and C and K are disjoint, vu denotes 
the time assignment over (7 U A7 Given a condition g G B{C) and a time 
assignment v G R^, we note v \= g when g holds for v. We define the timed 
automata (TA): 

Definition 1 A timed automaton A over A is a tuple (A, ?yo, G, A, /, Inv) where 
N is a finite set of nodes, t]q is the initial node, C is a finite set of clocks, 
E C N xB{C)xAx2^ xN corresponds to the set of edges: e = {g^g, ci, r, 77 ') G E 
represents an edge from the node g to the node g' with action a, r denotes the 
set of clocks to be reset and g is the enabling condition (the guard) over the 
clocks of A. We use the notation g vf . Moreover I : N 2^^ is a labeling 
function of nodes with atomic propositions. Finally Inv : N ^ B~ (C) is a 
function assigning an invariant to each node. 

Example 1 Consider the automata V , Pi and P 2 in Figure 1.1. The automaton P\ 
has four nodes, a\, b\, ci andcsi, one clock x\ and three edges. The edge between 61 
and Cl has f as action, {xi} as reset set and the enabling condition for the edge 
is xi < 1 . Node 61 has the invariant x\ <1 to enforce progress from the node before 
one time-unit elapses. The default invariant (for nodes a\, c\ and csi) is true. 

Note that the automaton V is a ^‘classical” automaton (without clock). □ 

A state or a configuration of an automaton A is a pair (g, v) where 77 is a 
node of A and v a time assignment for (7. Informally, the system starts at 
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node T]o with all its clocks initialized to 0 (i.e. with the time assignment vq). 
The values of the clocks may increase synchronously with time as long as the 
invariant requirement Inv{rjo) holds for the current values of the clocks . At 
any time, the automaton whose current node is r] can change node by following 
an edge u, r, 77') G E provided the current values of the clocks satisfy g. 
With this transition the clocks in r get reset to 0. Formally the semantics of A 
is defined as a labeled timed transition system: 

Definition 2 A labeled timed transition system over A is a tuple = (5 , sq , 

,/), where S is a set of states, sq is the initial state, ->C 5 x ^ U 0 x 5 is 

a transition relation and / : 5 »-)■ 2^^ a labeling function. We require that for 

any s E S and d G R, there exists at most one state s^ such that s s^. 
Moreover if exists, then exists for any 0 < d' < d. Finally (s^Y = . 

The labeled timed transition system associated with A is Sa = {Sa,(^o, — >a), 
where Sa is the set of states of A, do is the initial state (r]o, i;o), and — >a is 
the transition relation defined as follows: 

{r],v)--%{r]',F) iff 3 a, r, r/') G £* s.t. v \= g , F \= Inv{rf') and 

v' = [r 0]t; 

,v') iff q — Tf' and t’' = + d and {v d) [= I nv{r]) 

The labeling with atomic propositions is defined by: l{{rj, v)) = l{r])> Note that 
the condition {v d) [= Inv{rj) in the second rule implies that for any d' s.t. 

0 < d' < d we have (i; + d') [= Inv{r}) because invariants are conjunctions of 
X < k or X < k formula. 

Real-time systems may be modeled as parallel composition of timed au- 
tomata. Following [14] we suggest a composition parameterized with a syn- 
chronization function generalizing a large range of existing notions of parallel 
compositions. Let Ai,. . Anhen timed automata. A synchronization function 
f is a partial function (^U{«}) x . . .x (^U{*}) ^ A, where • denotes a distin- 
guished no-action symbol (for any i and rj £ Ni, we assume (77, tt, ♦, 0, 77) G Ei). 
In fact, / is an 72- ary synchronization function with renaming. We denote by 
{Ai I . . . \An) f the parallel composition of Ai,. . . ,A„ w.r.t. the synchronization 
function /. A network configuration is a pair {fj, v) where f\ ^ (771, . . . , 77^) is 
vector of nodes and 7; is a valuation for C = UjCt, i.e. the clocks of the network 
(we denote by V{ the restriction 

The semantics of (Ai| . . .|A„)/ can be defined as a labeled timed transition 
system whose states are the configurations of the network and the transitions 
are given by the two following rules: 

(77, v) ^ {f],v-\- d) iff Vi G {1 , . . . , 72}, {r]i, Vi) ^ {r]i,Vi + d) 

(fj,v ) iff Vi e s.t. ai G ^U{*} 

and F = v[. . . v'^ and f{ai , . . . , a„) = b 

Note that the first rule stipulates that all clocks increase synchronously. The 
atomic proposition labeling is done in a natural way: /((t 7,7;)) = Ud(77i). 
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Example 2 Consider again the automata V, P\ and P2 of figure 1.1. This system 
describes Fischer’s mutual exclusion protocol: two processes (modeled by Pi and P2) 
both try to reach a critical section (csi and CS2 resp.). To guarantee mutual exclusion 
of the critical sections, Pi and P2 share a variable (modeled by the process V ) which 
can be assigned to 0,1 or 2 by the processes. Moreover the current value of V can be 
read by the two processes. 

The protocol can now be modeled by the parallel composition FP = (V"|Pi|P2)/ with 
f the ternary synchronization function defined as follow: /(=0, =0, t) = /(=0, •, = 
0 ) == 0, /(a, a,#) = a for any a in {= 1, := 1} and /(a,t,a) = a for any a in 
{=2, :=2}. The values of f correspond to the name of the visible action. 

The coordinate systems in Figure 1.2 indicates (some of) the states of the system 
FP. Each point of the coordinate systems represents a unique time assignment for 
x\ and X2, with the coordinate systems representing states involving the nodes config- 
urations {vo, a 1,02), (vo,ai,b2), (1^0,61,62) and {vl,cl,b2) respectively. We indicated 
the following transition sequence : ((uo, ai , 02), (0, 0)) ((i^o, cti , «2 ), (1-3, 1.3)) 

((i;o, 01,62), (1.3,0)) ((i;o, 01,62), (1.5, 0.2)) ^ ((t;o, 61, 62), (0,0.2)) . □ 



SPECIFYING TIMED SYSTEMS IN CMC 

In our tool CMC, specifications of real-time systems are given as properties of 
the timed modal logic Lj, [16]. This logic may be seen as a fragment of the 
logic of [10] allowing only maximal fixed-points. Even though this restriction 
only enables safety properties to be specified and rules out liveness properties in 
general, it is still expressive enough to specify time-bounded liveness properties. 
In many real-time applications this is precisely what we wanted. Avoiding 
alternations of fixed-points also simplifies our model-checking algorithm. 

Definition 3 Let K a finite set of clocks, Id a set of identifiers, AP a set of 
atomic propositions, and A a set of actions. The set of formulae over K , 
Id, AP and A is generated by the following grammar: 

::= (f A \ ip \/ rp \ {a) (f \ [a] (p \ {5) ip \ [S] ip \ Z 
I x \n (p I ic + m txi y + m' | x [X rn | ap \ ->ap 

where a E A; x,y E K; m,m' E N,* m E E Id and 

ap E AP. 
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{■q,v,u) |=-p ^ AV> 


iff 


{t],v,u) <P and {r],v,u)\=vi^ 


{f),v,u) \=T) (a) (f 


iff 


{fj,v) — >{rj',v^)and u) \=x> ^ 


{fj,v,u) \=v {6) <f 


iff 


BdGRs.t. {fj,v) {fj,v + d) and 

{fj,v d,u-\- d) \=v ^ 


{fj, V, u) \=v [<J] <p 


iff 


Vd G R, (^, {fj, V d) implies 

{fj,v + d,u-\- d) \=v P 


[fj, V, u) |=p a; M m 


iff 


u{x) cxj m 


{fj,v,u) \=D x\nip 


iff 


{fj,v,[{x}y-^0]u) \=v p 


{rj,v,u) \=t> Z 


iff 


{fjjV^u) belongs to the maximal solution of Z = 'PiZ) 


{fj,v,u) p 


iff 


3i s.t. p£l{r]i) 


{fj,v,u) \=t) Aj-.p 


iff 


pel{r]j) 

Table 1.1 Semantics of Lj^. 



Note that we can easily define new operators as tt, f, v? => (if no identifier 
occur in (f). The meaning of the identifiers is specified by a declaration V 
assigning a formula of Lj, to each identifier. Given 5 = {Ai | . . . \ An)f a network 
of TA, we interpret the formulas of Lj, with respect to extended configurations 
(fj, V, u), where (fj, v) is a configuration of S and u is a time assignment for K. 
Whereas the classical modal operators (a) and [a] deal with action transitions, 
the operator (5) (resp. [S] ) denotes existential (resp. universal) quantification 
over delay transitions. 

The K clocks are so-called formula clocks, used as stopwatches for measuring 
the time elapsing between states (specified as properties) of the system. The 
formula clocks increase synchronously with the automata clocks. The formula 
(x in (p) initializes the formula clock x to 0 and the formula (x xi m) are used to 
compare the value of x in the current extended configuration with an integer 
value. 

Finally, an extended configuration satisfies an identifier Z if it belongs to the 
maximal solution of the equation Z = T^[Z). The atomic propositions can be 
of the form p or Aj :p (to specify that p holds for component Aj) and they can 
be in the scope of a negation. The formal definition of semantics is given in 
table 1.1 (V and [a] are dual cases of A and (a) ). 

Within Liy we may express a number of classical temporal (and timed) proper- 
ties. Let B he a subset of A. We have the following derived operators : 

■ ALWAYSe(v?) expresses that p holds from any state reachable using ac- 
tions of B and delay transitions. The AG operator of CTL corresponds 
to ALWAYS^. ALWAYSi 3 (^) can be defined by the following equation: 
X = ifA/\ [a]X A [S] X. 

aeB 

■ ^iUntil^^2 corresponds to the weak until operator of temporal logic (‘Vi 
holds unless p 2 holds, when following delay transitions and actions within 
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B”). To define Untilg, we can use the equation; 

X = [‘PI A[S] XA /\[a]x). 

a£B 

■ v^UpTo d (‘V will hold during at least d time units, whatever the per- 
formed transitions”) can be expressed with: a? in ((^UntiU(x >d)). 

Example 3 Let Mut(i 2 ) be the specification stating that P\ and P 2 can never reach 
the critical section at the same time (see example 2). To write such a specification 
we need to label the cst nodes by the atomic proposition CS. We have: Mut(i 2 ) = 
ALWAYS>i(-iPi:C’5 ViP2:C5) ^ = {=0, = 1, =2, := 1, :=2}. □ 

COMPOSITIONAL MODEL-CHECKING 

Quotient Principles 

Recall from the Introduction that we are interested in constructing (p/An such 
that (All • • • \^n) N if if (^i| • • -l^n-i) N p/An^ A first quotient 

construction for (dealing with timed automata without invariant nor atomic 
proposition) has been defined in [16] and a more efficient quotienting for a 
sublogic Ls has been given in [18, 15]. Here we present this new quotienting 
extended to Ljp. 

A network of timed automata is described by using a n-ary synchronization 
function but it is easier to consider binary synchronization between An and 
the remaining part to define the quotient construction. Since our synchroniza- 
tion function allows renaming, we can easily decompose a parallel composition 
(All . . . |An)/ as: ((Ai| . . . |An-i)/^' |An)// where f (resp. /") is a binary (resp. 
(n — l)-ary) synchronization function. 

In table 1.2, we define the quotient construction (the cases [a]p and p\/7p are 
dual cases of those presented), with the following convention: (•) p = [•]p = p. 
Moreover the formula r in p with r = {ci, . . . , c/} C C stands for ci in ... ci in p. 
We have the following theorem ^ : 

Theorem 1 Let Ai,. . . ,An be n timed automata {Ni,r]i^o, Ci, E{, k, Invi). Let 
p be a Lip formula over the set of clocks K, all over an action set A. Let 
{{p,T]),vw,u) be an extended configuration 0/ ((Ai | . . . |An-i)/^ lA^)/ with v G 

It; E and u G R^, then we have: 

{p, g), vw, \='p p if a,nd only if (^p, v, w [=p/ p/^ g 

Note that the clocks in Cn become formula clocks after the quotienting. More- 
over the quotienting rule for variables may increase the number of equations 
(in the declaration V' compared with the declaration V) since it creates a new 
variable for any variable Z in p and any node rj of the quotiented automa- 
ton. In order to avoid trading the acknowledged explosion problem of the global 
state space with a similarly harmfull explosion problem in the size of quotient 
formulas, it is essential that we find strategies for simplifying formulas. Note 
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(<Pi A <P2)/^ n = {<pi/^ ri) A (y>2/^ 77) Z/^ 77 = Z” 



((«)¥’)/, V 5A(rin/77t)(77')) A{6)(riny>/^77') 

T)^-^ rj'£EnS.t.f(b,c)=a 



(S) (f/^T]=. {S) ^Inv{r}) A (p/^ tj^ {x ix c) t] = {x c) 

[( 5 ] 77 = [ 5 ] (jnv(ri) ^ 77^ (x in p)/^ 77 = x in {p/^ 77^ 

r tt iff P = A„ A a e Ia„ in) 

(P : a)/ 77 = < ff iff P = A a ^ (77) 

[ (P: a) iffP#^„ 



. , / It iff a € 

*^'4 ^ ~ ^ a otherwi 



I A An) 

otherwise 



Table 1.2 



Structural definition of quotient p/^T] with rj a node of 



that contrary to the quotient defined in [16] we do not quotient the formula for 
any node and any clock region since we insert explicitly guards into the formula 
(and not only their truth value w.r.t. the regions). This explain why such a 
quotient is much more compact and more efficient than the first one. 

Example 4 The quotient o/Mut(i^ 2 ) the automaton V is {Xo,V') with V : 

Xo = (-Pi : CS V -P 2 : CS) A [= OjXo A [:= l]Xi A [:= 2]X2 A [S] Xo 

Xi =' (-Pi : CS V -P 2 : CS) A [= IjXi A [:= IjXi A [:= 2]X2 A [S] Xi 

X 2 = (-Pi : CS V - 1 P 2 : CS) A [= 2]X2 A [:= IjXi A [:= 2]X2 A [5] X 2 

□ 

Now, let 7T be the binary synchronization function completely specified by 
7 r(#,a) = a for all a G .4 (i.e. the left argument to tt is completely ignored). 
Then it is easy to see that any timed automaton A is strongly bisimilar ^ to the 
network {nil\A)T: and hence can be proved to satisfy the same formula of 
Using this observation, the quotient construction can be used to obtain alter- 
native model-checking algorithms for Lj, as follows: A]p^ p [nil\A)T: |= (p 
<=> nil \= ip I A. Due to the projective nature of tt it is clear that p/ A contains 
no action modalities, and it is easy to build a special purpose model-checker 
for the simple automaton nil. 

Note that the quotient definition would support the introduction of negation 
in the logic (by a simple propagation) and this would allow to use minimal 
fixpoint in the specification and then increase its expressive power. Nevertheless 
such an extension would require to adapt the simplification rules. 
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Simplification Strategies 

We have seen in the previous section that repeated quotienting leads to an 
explosion in the formula. This phenomena was already observed in [16, 18, 15] 
and in the untimed case in [3] . An efficient way to avoid this explosion consists 
in applying simplification rules after each quotient. 

First we need simplifications to tackle the explosion due to the parallel com- 
position (occurring with the quotienting of the variables) . This can be done by 
using the classical rules already used in the untimed case: 

• Boolean Simplification. Formulas may be simplified using the following sim- 
ple boolean equations and their duals: fA(p = f,ttA(p = (p, (a)f = f , (S ) ff = f , 
X in f = ff, A [ajf = f. 

• Constant Propagation. Identifiers which are declared to either tt or ff may 
be removed while substituting their definitions in other equations. 

• Trivial Equation Elimination. Equations of the form X = [a]X are easily 
seen to have X = tt as solution. More generally, X can be replaced by tt when 
9 ?[tt/X] ^ (with X can be simplified to tt. 

• Equivalence Reduction. If two identifiers X and Y are equivalent (i.e. are 
satisfied by the same timed transition systems) we may collapse them into a 
single identifier. 

Secondly we have to add special simplifications to deal with the clocks con- 
straints. Indeed the major problem in the real-time systems analysis consists 
in the treatment of time encoding: simplifying test or reducing the number of 
clocks used in the specification can be crucial to succeed in the verification of a 
system. We developed several strategies which have been evaluated with CMC. 
Here we present two simplifications which can be combined together and which 
lead to interesting results. The main idea is that we are interested in the truth 
value of a specification <p for extended configurations (s,uq) (with s a network 
configuration) with all formula clocks equal to zero. Using this information, it 
is sometimes possible to simplify the tests inside (p: 

• Hitzone Reduction. Consider the formula ^ == [a] {x > 1). Clearly is 

equivalent to [ajff for any extended configuration (s, uq) because no a-transition 
can modify the value of the formula clock x (which is still equal to 0 after the 
transition). A more complex example is: ip = [5] {x > I => [a] a: < 1); for the 
same reason, ip is equivalent to [S] (a? > 1 [a] ff). 

Given a specification the principles of Hitzone reduction is to compute for any 
test t occurring in (p the clock constraints St (i.e. the set of time assignments for 
the formula clocks) which are effectively needed to evaluate the truth value of 
(p for any (s,uo). Given this information (obtained by a fixpoint computation) 
we can simplify by tt (resp. ff) the tests t for which the truth value is true (resp. 
false) for every time assignment in St . 
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A more interesting example is the simplification of 9? = ( Aq , V) with the 
following declaration V: 

Xo = [a]{xi\nXi)A[S] Xo 
Xi = [6] (X 2 in X 2 ) A [5] Xi 

X2 = XI>X2A [(j] As 

An observation of the declaration shows that the truth value of X2 is always 
considered from Xi after a reset of X2 or from its own definition. Then the 
test Xi > X2 in X2 will always be equal to tt, therefore X2 becomes a trivial 
equation and therefore Xi too. Finally Xq can be reduced to tt. 

• Constraint Reduction. Another way to simplify the tests inside the formula 
is to compute the constraint associated to each variable X, that is the set of 
timed valuations which can satisfy the tests in its definition. For example, the 
constraint of A a? < 1 A (a)(y < 2) is [x < 1 A y < 2]: for any extended 
configuration (tJjV,u) satisfying A, we have uj=x<lAy< 2 . Each Lj, op- 
erator has its own rule to propagate the constraint and a fixpoint computation 
is necessary to obtain the final constraint of any variable. For example, the 
constraint of a variable A x < 1 A . . . A [(5] A will be empty and A is then 
equal to f . 

Finally it is possible to combine the Hitzone and the Constraint redusctions 
to simplify the tests inside the formula. Note that these two simplifications 
assume that the formula clocks and automata clocks are disjoint: we assume 
that the action transitions do not modify the value of formula clocks. Without 
these simplifications, we could use automata clocks in formula. 

Example 5 Recall Example 2. Without simplification (except boolean reductions) 
the quotient specification mutu lfVljP\ljP 2 contains 18 identifiers. Applying the 
minimization strategies of the CMC tool we find that mutnlj V If Pijj P 2 is equivalent 
to tt. Then the property holds for the system. □ 

o Why it is efficient ? Quotienting immediately followed by the various sim- 
plification strategies often allows to dismiss parts of the quotiented component 
which are irrelevant to the specific property in question. Also, the iterative 
strategy allows to deal with clock constraints after each quotienting i.e. before 
considering all clocks of the system, thus making simplification easier and more 
efficient (this will be clearly illustrated by Fischer’s mutual exclusion protocol). 

EXPERIMENTAL RESULTS WITH CMC 

The compositional method has been implemented in the CMC ^ tool (written 
in C“h+) : it contains a command language and an environment to define 
networks of TA and L*/ specifications, and several functions to build quotient, 
to simplify formula (every reductions described in the previous sections has 
been implemented) . . . Moreover it contains a Check procedure to decide if a 
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formula holds for the nil process. It is also possible to verify if two timed 
automata without invariant are bisimilar. 

In this section we present two examples verified with CMC. The first one is 
Fischer’s mutual exclusion protocol, which is a benchmark in the timed veri- 
fication area. This example is interesting because it shows both the power of 
compositional approach and its limits. Here we address the two classical ver- 
sions of the protocol and we present a third one. 

The second example is the train crossing example. Its purpose is to show that 
Li, is an expressive specification language: we write a short specification in- 
cluding safety properties, bounded liveness property etc. Moreover, whereas 
Fischer’s protocol has a symmetrical structure potentially making the com- 
positional approach more efficient, the train crossing example has no special 
structure thus showing that the method is not limited to special systems but 
can be applied to arbitrary networks of timed automata. 

Fischer^s mutual exclusion protocol 

Fischer’s mutual exclusion protocol described in the example 2 is a bench- 
mark of the verification of timed systems. Consider n processes P{, the prob- 
lem is to verify that at any time at most one process can access its criti- 
cal section: we want to verify that for any i,j £ {!,..., n} with i j, 
Mut(i j) holds for the initial configuration of the system. Remember that 

Mut(ij) = ALWAYS^ (-Pi V-Pj:csj). 



In order to verify Mut(i 2 ) efficiently, we need to carefully choose the order 
in which the processes are quotiented. In fact, since Mut(i 2 ) only directly deals 
with the processes V, Pi and P 2 , we may hope that quotienting these three 
components will suffice for determining the truth value of the formula. Using 
CMC, we start by quotienting U, then P\ and finally P 2 . The simplification 
rules allow to deduce tt ! To evaluate the efficiency of the method we give the 
size of the specification (i.e. the number of variables). For example, we have 



the following computation ^ 


for n — 100: 






Quotient by . . . 


VlOQ 


Pi 


P 2 


Size of specification: 


202 102 


404 202 


800'-+, 0(tt) 



These results can be read as follows: The quotient of Mut(i 2 ) by Uioo gives a 
specification with 202 variables which are reduced to 102 after the simplifica- 
tions, then the quotient by Pi gives 404 variables which are reduced to 202, and 
finally the quotient of P 2 gives 800 variables which are reduced to the single 
formula tt. 

Of course a complete verification needs to do such a computation for any 
Mut(, j) but by choosing the right order for removing the components the pre- 
vious result shows that the method can be successfully applied. Note that the 
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Pi Pi 

Complete version Revisited complete version 

Figure 1.3 The complete version of Fischer's mutual exclusion protocol and a variant. 

compositional approach is very efficient in this case: other existing real-time 
verification tools cannot verify this protocol with more than 15 processes. 

In fact the previous version of Fischer’s mutual exclusion protocol is not the 
complete protocol. The complete version is cyclic and is described on the left 
part of figure 1.3. The main point is that a process using the critical section 
can leave it and then reset the variable V . This version is much more difficult 
to verify. Indeed if we quotient Mut(i 2 ) (in which we add a term [:= 0 ]X in the 
conjunction) by 1 /, Pi and P 2 , we cannot deduce tt (contrary to what we claim 
in [15]) because at this step we know, thanks to the synchronization function, 
that other processes can perform the := 0 action and we have no information 
about when they can perform it. Typically if P 3 was just a process able to 
reset V at any time, then P 2 could access the critical section at the same time 
as Pi. Then for this version of the protocol, we need to quotient all processes to 
finally deduce tt. And in this case, we cannot avoid the explosion of the size of 
the specification and we are limited to small systems. We obtain the following 
computation for 6 processes: 

I Ve I Pi I P2 I P3 I P4 I P5 I Pe I 

I 14-^3 8 I 30 '^s 20 I 74 29 | 106 45 | 162 -->3 69 | 242^^3 101 | 338 '^3 0 | 

Note that for this version, the newest BDD approach proposed in [7] for KRO- 
NOS can deal with 14 components. Nevertheless we can consider a third version 
of the Fischer protocol. It is described in the right part of the figure. The main 
idea is to see the reset of the variable as a reset of the protocol: when a process 
leaves the critical section, then it resets the variable and all processes receive 
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Traini 


Train2 


Controller 


Counter 


Gate 


1 visible action 


Appl 


• 


Applincrl 


Incr? 


• 


App 


- 


Appl 


App? I ncrl 


Incr? 


t 


App 


Exitl 


• 


Exit?Resetl 


Reset? 


• 


Exit 


Exitl 


• 


ExitlDecrl 


Deer? 


• 


Exit 


• 


Exitl 


ExitlResetl 


Reset? 


• 


Exit 


• 


Exitl 


Exit? Deer 1 


Deer? 


• 


Exit 


• 


• 


GoUpl 


• 


GoUp? 


GoUp 


• 


• 


GoDownl 


• 


GoDown? 


GoDown 


i 


• 


• 


• 


• 


i 


• 


i 


• 


• 


• 


i 


• 


• 


• 


• 


i 


i 



Table 1.3 Synchronization table for (Train i | Train2 | Controller | Counter | Gate). 



this signal and go back to their initial state. To obtain such protocol it is 
sufficient to synchronize the Reset action over all processes. Note that the pro- 
tocol is still cyclic and if such a change simplifies the protocol, it remains quite 
reasonable. In this case, we succeed ® in applying the compositional approach: 



Quotient by . . . 


Vioo 


Pi 


P2 


Size of specification: 


202 102 


404 301 


1194 0 



The train crossing example 

We now present a version of the classical railroad crossing example to illustrate 
the expressive power of Li^. The network of timed automata (Traini | Traiu 2 | 
Controller | Counter | Gate)/ in figures 1.4, 1.5 and 1.6 models a train crossing: 
The trains can send an App\ (resp. Exitl) message to a controller to inform 
it of their arrival in (resp. departure from) the section before (resp. after) 
the gate. The gate can receive orders from the controller and can change its 
position (open or close) in at most 10 seconds. 

The controller uses the same strategy as the one presented in [8] : the idea is to 
count the number of trains which are staying between the App point and the 
Exit point and to use this information to decide if an Exitl message has to 
be followed by a GoUpl order. To model this strategy we use the automaton 
Counter whose nodes correspond to the possible values (bounded by 2). The 
synchronization function is given in table 1.3 and has to be read as follows: 
An App action of the system corresponds to a Appl action performed by one 
of the trains, a App?Incr\ action of the controller and a Incrl action of the 
counter. Note that the distinction between Reset? and Deer? allows us to 
deduce whether there remains only a single train in the section. 

In this example, we use name of nodes as atomic propositions. 
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Exit?Decr\ App?Incr\ Exit?Decr\ Exit?Reset\ 




c < 10 ] 



Specifying with Lj,. An important point of CMC is the expressivity of its 
specification language, Lj/, which allows application specific properties to be 
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expressed concisely. The aim of this part is to illustrate this point by specifying 
the train crossing example. Clearly we expect the following two properties to 
hold: 



■ “When a train is on the rail crossing, the gate is close”. This property 
can be expressed by the formula: 

V^safe == ALWAYS^i ^(Traini : on V Train 2 : on) => Gate:close^ 

■ “The gate is open in at most Si seconds after an Exit signal if no train 
approaches the railroad crossing inbetween” . We can use the formula: 

‘Piive{Si) = ALWAYS^ [(z<J/)UntiU\^ppGate : open]^ 

Note that the restriction on the set of allowed actions in Until is useful in 
capturing the “if” part of the informal statement of the property. 



However, in addition to the application specific properties above, we also want 
to ensure that the model is realizable or physically valid and possesses no 
unreasonable behavior: 



■ “There is no deadlock in the model: it is always possible to wait for some 
delay such that an action (App, Exit, i, GoUp, GoDown) is enabled”. 
We can use v^no_di with: 



<^no_di ALWAYS^ .(<J) ^(f)ttV(App)ttV(£'xit)ttV(GoZ)ou;n)ttV(Gc>C/p)tt^ 



■ Bounding the counter with 2 is sufficient: “the error state is not reach- 
able”. This can be expressed by ^©rr — ^ ALWAYS>i(-'Counter : error). 

■ Actions App?, Exit?, GoDown? and GoUp? correspond to the reception 
of signals: they have to be enabled when a corresponding signal can be 
sent (unless this could prevent possible behaviors) . The property clearly 
holds for App and GoDown but it is unclear for Exit? because there 
is no transition Exit? from up node in the controller. We can use : 
V^signai — ^ ALWAYS^ ((E'xif!) tt => (Exit?) tt). 

Note that to verify this property we have to add in the synchronization 
table that an Exitl (resp. Exit?) signal can be performed by one of 
the train without synchronization (resp. by the controller with actions 
Exit?Reset\ or Exit?Decr\ with a synchronization over Counter actions). 
Being able to express such a property with Li, is important because it gives 
a good help for the model construction. 

Results. For our train example, we have the following results 
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/ Train 1 
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II 
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17 it. 


II 


No 1 


1 ^no«dl 


II 


14^,14 


1 66--.50 1 


154--, 112 1 


98-,65 1 


237-, 83 


II 


7 it. 


II 


Yes 1 


1 ^err 


II 


6^,6 


1 27--.27 1 


65-, 59 1 


00 
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- 


II 


- 


II 


Yes 1 


1 ^signal 


II 


11^,10 


1 40-V..33 1 


79-, 68 1 


61--.42 1 


124-,51 


II 


5 it. 


II 


Yes 1 



The column ‘^Check” contains the number of iterations (of the fixpoint com- 
putation) used by the Check procedure to decide if 9 ?/Traini/Train 2 /Controller 
/Counter/Gate holds for the nil process when the formula has not already been 
reduced to tt or f by the simplifications. The last column gives the final answer 
(Yes or No) for 5 

Note that for <^err it is not necessary to quotient all automata: the analysis 
of a subpart of the system allows to verify that this formula holds for the system. 



CONCLUSION 

Since the introduction of the compositional method in [16], substantial improve- 
ments have been achieved. In particular, the tool CMC presented in this paper 
offers a collection of new simplification heuristics adding to the efficiency of the 
overall method. Partially based on the experimental results of this paper, our 
conclusion is that (1) the compositional method is efficient and not limited to 
special types of networks of timed automata and (2) the timed modal logic Li^ 
constitutes a convenient specification language. 

The future development will concern the elaboration of new simplifications 
(based on partial evaluation of formula) and an optimization of the data struc- 
ture to encode the clocks constraints. 
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Notes 

1. The proof is omitted due to space limits but it is very similar to the proofs of [16, 18] 
but a long version of this paper including the proof is available by email. 

2. We extend the notion of strong bisimulation to require that delay transitions are 
matched by delay transitions of equal time-quantity. 

3. (^[tt/X] is the formula obtained by substituting all occurrences of X in with the 
formula tt. 

4. CMC can be obtained by sending an email to f lSlsv.ens-cachan.fr. 
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5. This has been done in few minutes on a SUN Ultra Sparc 1 with 64 Mb memory 

6. This computation takes approximately one hour on a SUN Ultra Sparc 2 with 512 Mb. 

7. All these results have been computed on a Sparc Ultra 1 with 64 Mb memory in few 

seconds except for ^iive(^^) which needs approx 6 minutes. 
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AbstrdCt: We present TwoTowers, a tool for analyzing functional and performance 
properties of concurrent systems expressed as terms in the stochastically timed reward 
process algebra EMPAr. TwoTowers builds on two existing tools, CWB-NC andMarCA, 
that have been retargeted to carry out functional and performance analysis (respectively) 
of EMPAr system specifications. As an example, we describe the application of TwoTow- 
ers to the Lehmann-Rabin randomized distributed algorithm for the dining philosopher 
problem. 

INTRODUCTION 

The desirability of taking account of the performance aspects of a system in the early 
stages of its design has been widely recognized [23, 10, 13, 7]. Nevertheless, it often 
happens that a concurrent system is tested for efficiency only after it has been fully 
designed and tested for functionality. This results in two problems. On the one 
hand, the detection of poor performance causes the system to be designed again, so 
the cost of the project increases. On the other hand, since the performance-related 
analysis is done on a model of a system extracted from the implementation while the 
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functionality-related analysis is usually performed on a model derived from a system 
design, great care must be taken to ensure that these models are consistent with one 
another, i.e. do reflect (different aspects of) the same system. 

In order to solve the two problems above, in [3, 4] a two-phase approach for 
modeling and analyzing both functional and performance characteristics of concurrent 
systems has been proposed, which is based on stochastically timed process algebras 
and stochastically timed Petri nets in order to exploit their complementary advantages: 

■ The first phase requires the designer to specify the concurrent system as a term 
in the stochastically timed process algebra. Because of compositionality, the 
designer is allowed to develop the algebraic representation of the system in a 
modular way: every subsystem can be modeled separately, then these models can 
be put together through the operators of the algebra. The analysis of the algebraic 
term is then carried out on its underlying integrated interleaving semantic model, 
which is a transition system labeled with both action types and durations. The 
integrated interleaving semantic model can be analyzed as a whole by a notion 
of integrated equivalence or projected on a functional semantic model and a 
performance semantic model that can be analyzed by means of existing tools. 

■ The second phase consists of deriving from the algebraic representation of the 
system an equivalent representation in the form of a stochastically timed Petri 
net. The net representation turns out to be useful whenever a less abstract repre- 
sentation is required highlighting dependencies, conflicts, and synchronizations 
among system activities, and helpful in detecting some properties that can be 
easily checked only in a distributed setting. Additionally, the net representation 
is usually more compact than the integrated interleaving semantic model result- 
ing from the algebraic representation, since concurrency is kept explicit instead 
of being simulated by alternative computations obtained by interleaving actions 
of concurrent components. The functional and performance analysis of the net 
representation can then be undertaken using existing tools. 

Since the two phases above are complementary, the choice between them is made 
according to the adequacy of the related representation with respect to the analysis of 
the system under consideration and the availability of the corresponding tools, In any 
case, the designer is suggested to start with an algebraic representation of the system in 
order to take advantage of compositionality of algebras and avoid graphical complexity 
of nets. 

This paper describes our efforts to provide tool support for the first phase of this 
approach through the implementation of a tool called TwoTowers. To use TwoTowers, 
the designer first specifies the concurrent system as an algebraic term. The algebra 
adopted in the tool is EMPAr [1], an extension of the stochastically timed process 
algebra EMPA [5] allowing for the specification of performance measures based on 
rewards, which augments the expressive power of a classical process algebra with 
additional features for expressing probabilities, priorities, and timing characteristics of 
systems. Because EMPAp supports compositional modeling, the designer may develop 
the algebraic representation of the system in a modular way; every subsystem can be 
modeled separately, then combined using the appropriate operators. Another useful 
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feature of EMPAr is that many functional properties of a system may be examined 
independently of performance properties and vice versa. Our implementation of 
TwoTowers exploits this fact by using two existing tools (that we have retargeted 
to EMPAr) for the analysis of these types of properties. CWB-NC [9] provides a 
variety of different types of analysis (e.g. model checking, equivalence checking, 
preorder checking, reachability analysis) of the functional behavior of systems, while 
MarCA [21] conducts stationary and transient performance analysis, as depicted in 
Fig. 1.1. 




Figure 1 .1 TwoTowers builds on CWB-NC and MarCA. 



The purpose of TwoTowers is similar to that of other stochastically timed process 
algebra based tools, such as the PEPA Workbench [11] and the TlPP-tool [14]. How- 
ever, besides the difference in the expressive power of the algebras used by these 
tools [5], the underlying philosophy is quite different. TwoTowers profits from two 
well-known software tools to carry out the functional and performance analysis. This 
is advantageous both from the point of view of the implementors and from the point of 
view of the users. We needed not to write code for implementing the analysis routines, 
thereby making the development of TwoTowers itself easier and faster, and users are 
provided with a wide range of automated techniques helping them during the study of 
systems. 

The remainder of the paper is organized as follows. In the second section we 
present the language of TwoTowers, i.e. EMPAr. In the third section we present the 
architecture of TwoTowers. In the fourth section we describe our use of the tool to 
study the Lehmann-Rabin randomized distributed algorithm for the dining philosopher 
problem. Finally, in the fifth section we report some concluding remarks about related 
work and future extensions of TwoTowers. 
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THE LANGUAGE OF TWOTOWERS: EMPAr 

The building blocks of EMPAr [ 1 ] are actions. An action is a quadruple < a , A , r i , ?2 > 
where: 

■ a is the type of the action. Types divide actions into external and intenuxl 
(denoted by action type r) depending on whether they can be seen by an external 
observer or not. 

■ A is the rate of the action, i.e. a concise way to represent the random variable 
specifying its duration. Based on rates, we have the following classification: 

- Exponentially timed actions are actions whose rate is a positive real num- 
ber. Such a number is interpreted as the parameter of the exponentially 
distributed random variable specifying the duration of the action. 

- Immediate actions are actions whose rate, denoted by oo;_u,, is infinite. 
Such actions have duration zero and each of them is given a priority level 
I € N+ and a weight w; € R+, useful for expressing prioritized and 
probabilistic choices respectively. 

- Passive actions are actions whose rate, denoted by *, is undefined. The du- 
ration of a passive action is fixed only by synchronizing it with a nonpassive 
action of the same type. 

The restriction to exponentially distributed durations implies that the semantics 
can be defined in the interleaving style, thanks to the memoryless property 
of exponential distributions, and that the underlying performance models are 
Markov chains. 

■ fi and V2 are, respectively, the yield reward and the bonus reward of the ac- 
tion [15]. Both of them are included within actions to allow for a high level 
specification of the performance measures of interest. The former expresses the 
speed at which gain is accumulated at the state executing the action, whereas 
the latter expresses the gain awarded upon executing the action. Performance 
measures are computed as weighted sums of state probabilities and transition 
frequencies, where rewards are used as weights. 

We denote by 

Actr = {<a,A, fi,r2> € AType x ARaie x AYReward x ABReward \ 

X = * fi = ?2 = *} 

the set of actions, where AType is the set of types, A Rate — R+ U Inf U {♦}, with 
Inf = {oo;,,;, I / € R+ A G R+} is the set of rates, AYReward = R U {*} is the 
set of yield rewards, and A BiJewarrf = R U { * } is the set of bonus rewards. 

Let Const be a set of constants and ARFun = {ip : AType — > AType \ p{t) — 
T A p{AType - {r}) C AType — {r}} be a set of action relabeling functions. The 
set Cr of process terms of EMPAr is generated by the following syntax 

::= 0 I <a,\,ri,f2>-E \ Ejl \ E[p] \ E E \ E\\s E \ A 
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where L,S C AType - {r} and A G Const. We denote by the set of guarded and 
closed terms of Cr- 

The null term “ 0 ” represents a termination or deadlocked state. The prefix operator 
“<a, A, ri, r2>- ’ denotes the sequential composition of an action and a term. The 
functional abstraction operator “_/L” hides the actions whose type belongs to L by 
changing their type to r. The functional relabeling operator “-[9?]” changes the types 
of actions according to (p. The alternative composition operator -j- expresses a 
choice between two terms: the choice is resolved according to the race policy when- 
ever exponentially timed actions are involved (the fastest one succeeds) or according 
to the preselection policy whenever immediate actions are involved (only the actions 
having the highest priority level are executable and each of these is given an execution 
probability proportional to its own weight), while the choice is purely nondeterminis- 
tic whenever passive actions are involved. The parallel composition operator ||5 
expresses the concurrent execution of two terms according to the following synchro- 
nization discipline: two actions can synchronize if and only if they have the same type 
belonging to S and at most one of them is not passive. Finally, constants together with 
their corresponding defining equations of the form A = E allow for recursion. 

Given a term E G Gn its integrated interleaving semantics Ir{E} is represented 
as a transition system with action-labeled edges. Because of the presence of actions 
with different priorities, as well as the fact that immediate actions take precedence 
over exponentially timed ones due to the race policy, the integrated interleaving model 
is generated by a two-layer semantics: first all the potential moves are derived, then 
those with lower priority are discarded. The states of XrlE} are divided into tangible, 
vanishing, open, and absorbing depending on whether they have outgoing exponen- 
tially timed transitions, outgoing immediate transitions, outgoing passive transitions, 
or no outgoing transitions. E G is said to be performance closed if Xr[E] does not 
contain passive transitions; we denote by Xr the set of performance closed terms of Gr- 

From the integrated interleaving semantic model, two projected semantic models 
can be obtained. The functional semantics of E E Gr is still represented as a transition 
system Er{E} now labeled by action types only, derived from Jr[E] by dropping 
action rates and rewards. The performance semantics of E G Xr is represented as a 
homogeneous Markov reward chain basically derived from Ir[E] by dropping action 
types and by lifting yield rewards from transitions to states: the yield reward earned 
by a state is the sum of the yield rewards earned by its outgoing transitions. To be 
more precise, the performance model is given by a homogeneous continuous time 
Markov reward chain or a homogeneous discrete time Markov reward chain depending 
on whether lr\E\ contains only exponentially timed or immediate transitions. If 
both kinds of transition coexist, the performance model is a homogeneous continuous 
time Markov reward chain built by applying to Ir[E] a suitable graph reduction rule, 
which eliminates vanishing states together with their outgoing immediate transitions 
and modifies rates of transitions entering such states accordingly. 

For a more formal presentation of EMPAp semantics, the interested reader is referred 
to [1,2]. 
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ARCHITECTURE OF TWOTOWERS 

The architecture of TwoTowers is depicted in Fig. 1.2. TwoTowers is composed of a 
graphical user interface, a tool driver, an integrated kernel, a functional kernel, and a 
performance kernel. 




Figure 1 .2 Architecture of TwoTowers. 

The graphical user interface is written in Tcl/Tk [20] and allows the user to edit 
EMPAr specifications, compile them, and run the various analysis routines. 

The tool driver, which is written in C [17] and uses Lex [19] and YACC [16], 
includes routines for parsing EMPAr specifications and performing lexical, syntactic 
and static semantic (closure, guardedness, finiteness) checks on the specifications. 
If there are errors, a message indicates the number of errors and a file is generated 
pinpointing the errors in the specification source file. When there are no errors, the 
syntax tree of the specification is produced for analysis by the three kernels. 

The purpose of the integrated kernel is to perform those analyses that require 
both functional and performance information and therefore cannot be performed by 
factoring out information to be passed to either the functional or performance kamels. 
The integrated kernel, which is implemented in C, contains the routines to generate the 
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integrated interleaving semantic model of correct EMPA^ specifications. The model 
generation employs the transition caching strategy proposed in [8] to store certain 
semantic information during model construction thereby avoiding recomputation of 
this information and saving time and memory. After generating a model the tool 
reports the number of states (classified as tangible, vanishing, open, or absorbing) as 
well as the number of transitions (classified as observable or invisible according to 
their types, and as exponentially timed, immediate, or passive according to their rates). 
Moreover, the integrated kernel contains a routine to check two EMPAp specifications 
for strong extended Markovian reward bisimulation equivalence [ 1 ], cis well as a facility 
for simulating an EMPAp specification which supports the derivation of performance 
measures according to the method of independent replications [22]. 

The functional kernel, which is written in C, generates the functional semantic 
model of correct EMPAp specifications. The analysis of the labeled transition systems 
as well as the terms themselves is then performed by a version of the Concurrency 
Workbench of North Carolina (CWB-NC) [9] that was retargeted for EMPAp using the 
Process Algebra Compiler of North Carolina (PAC-NC) [8]. The functional semantics 
of EMPAp along with a syntactic description of EMPAp were encoded as input to the 
PAC-NC which then produced the code to retarget the CWB-NC to EMPAp. The 
TwoTowers functional kernel therefore comprises all the analysis capabilities of the 
CWB-NC including interactive simulation of systems, reachability analysis to check 
safety properties, model checking in the //-calculus or CTL, equivalence checking, and 
preorder checking. 

Finally, the performance kernel, which is written in C, generates the Markovian 
semantic model of correct performance closed EMPAp specifications. The analysis of 
the Markov reward chains is then carried out by means of the Markov Chain Analyzer 
(MarCA) [21]: transient and stationary probability distributions are calculated, then 
performance indexes are derived using the rewards expressed in the specifications 
themselves. 

ANALYSIS OF A DISTRIBUTED ALGORITHM 

In this section we describe our use of TwoTowers to analyze the Lehmann-Rabin 
randomized distributed algorithm for the dining philosopher problem, which is char- 
acterized as follows. Suppose there are n philosophers P*, 0 < / < n - 1, sitting at 
a round table each with a plate in front of him/her. Furthermore, let there also be n 
chopsticks Ci, 0 < i < 7/ - 1, each shared by two neighbor philosophers and used 
to get the rice at the center of the table. Given that philosophers can be thought of 
as concurrent processes sharing resources represented by the chopsticks, the mutual 
exclusive use of the chopsticks must be guaranteed in such a way that no adjacent 
philosophers are simultaneously eating and deadlock does not occur. 

A fair and elegant solution to this problem has been proposed in [18]. The idea is 
that Pi flips a fair coin to choose between and gets the chosen chopstick as 
soon as it becomes free, and gets the other chopstick if it is free. If the second chopstick 
is not available, the philosopher replaces the first one and repeats the procedure. If 
we denote by +n - ’ (“- ~n -0 the addition (subtraction) modulo ?/, and let thmki 
be the action type is thinking'’, eati be ''Pi is eating”, pu- be ‘Y \ is being picked 
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up”, and prf, be “Cj is being put down”, this algorithm can be modeled as follows with 
EMPAp: 

I^Pn = (Pq 11® • • • II 0 ^n-l) l|{p«;,p<i(|0<i<n-l}(6'0 II® • • • llu f'n-l) 

Pi = <thinki,Xi,0,0>.P- 

p! = <T,OOi,i/2,0,0>.<pM,-,OOi_i,0,0>.(<pM, + „l,OO2,l,0,0>.i^" + 

<prf,-,ooi,i,0,0>.P/) + 

<T, 001,1/2, 0, 0>.<p«i+„i , 00i,i, 0, 0>.(<pw,-, 002,1, 0, 0>.P/' + 

<K+„1. 001,1. 0.0>-P/) 

P" = <ea<i,/<i, l,0>.<prfi, 001 , 1 , 0,0>.<p</j+,,i, 001 , 1 , 0,0>.Pi 

Ci = <pUi, *,*,*>. <pdi,*,*,*>.Ci 

where the r actions correspond to coin flips with the weights reflecting the respective 
probabilistic outcomes. It is worth noting that only actions with type ihinki or eaii are 
relevant from the performance viewpoint and so they have been given an exponential 
timing, whereas the time it takes P, to flip the coin or to pick up or put down a chopstick 
can be neglected so the corresponding actions are immediate. We also point out that 
priority levels of immediate actions have proven to be quite helpful in the description 
of the choice between getting the second chopstick and releasing the first one in order 
to model the fact that, whenever the second chopstick is available, the philosopher 
does pick it up. This is achieved in the subterms of term P- enclosed in parentheses by 
assigning priority level 2 to the action with type pu and priority level 1 to the action 
with type pd. 

Now, we apply TwoTowers to the algebraic description of the algorithm in order 
to automatically verify that no adjacent philosophers be simultaneously eating and 
deadlock be avoided (functional properties ensuring the correctness of the algorithm), 
and to automatically assess the mean number of philosophers who are simultaneously 
eating (a performance index reflecting the degree of parallelism of the algorithm). To 
verify the two functional properties, we can resort to model checking by proving that 
every state satisfies respectively 

n — 1 

<^i = A A {{eati+^i)tt V (ea<,_„i)it)) 

1 = 0 

and 

<f>i = {-)tt 

The mean number u of philosophers who are simultaneously eating is instead obtained 
by summing up the steady state probabilities of any state of the underlying Markov 
reward chain multiplied by the number of philosophers eating in that state, which is 
derived by yield reward I assigned to action having type eat,- in term P”. 

In Table 1.1 we summarize the results we have obtained by varying the number n 
of philosophers from 3 to 6, where A, = 4 and /i, = 0.75 for any 0 < i < n - 1. The 
columns show, respectively, the number of philosophers, the number of states of the 
integrated interleaving semantic model, the number of tangible states (which coincides 
with the number of states of the Markov reward chain), the number of vanishing states, 
the number of transitions, the number of exponentially timed transitions, the number 
of immediate transitions, the absence of adjacent philosophers simultaneously eating 
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Table 1 .1 Results of the analysis of the Lehmann-Rabin algorithm. 



n 


states 


ts 


vs 


transitions 


ett 


it 


01 


02 


V 


3 


109 


13 


96 


147 


27 


120 


yes 


yes 


0.999084 


4 


387 


35 


352 


620 


100 


520 


yes 


yes 


1.758340 


5 


1101 


81 


1020 


1655 


285 


1370 


yes 


yes 


1.975830 


6 


3199 


199 


3000 


5070 


846 


4224 


yes 


yes 


2.530878 



(verified by means of CWB-NC), the absence of deadlock (verified by means of CWB- 
NC), and the mean number of philosophers who are simultaneously eating (computed 
by means of MarCA). 

CONCLUSION 

In this paper we have presented TwoTowers, a tool based on the stochastically timed 
reward process algebra EMPAr for the analysis of functional and performance prop- 
erties of concurrent systems. TwoTowers generates the semantic models of algebraic 
specifications; then the task of studying such models is transferred to two already ex- 
isting toots: CWB-NC for functional verification, MarCA for performance evaluation. 
Relying on existing tools is advantageous from the point of view of both implementors 
and users. We needed not to write code for implementing the analysis routines, thereby 
making the development of TwoTowers easier and faster, and users are provided with 
a wider range of automated techniques. 

In this paper we have applied TwoTowers to the Lehmann-Rabin randomized dis- 
tributed algorithm. More complex systems have been analyzed by means of TwoTow- 
ers, such as the alternating bit protocol [4], CSMA/CD [2], ATM switches supporting 
different services [2], and an adaptive mechanism for trasmitting packetized audio over 
the Internet [6]. When dealing with larger state spaces, suitable techniques should be 
employed to reduce the cost of the analysis: 



■ As far as functional verification is concerned, TwoTowers provides the user with 
the techniques implemented in the CWB-NC, such as on-the-fly model checking 
and compositional minimization. 



■ From the performance evaluation standpoint, all the techniques implemented in 
MarCA are available in TwoTowers, together with the support for simulative 
analysis which allows infinite state systems to be handled. Moreover, in the 
future capabilities for the detection at the syntax level of product form solutions 
(see e.g. [12]) shall be added. 



■ The planned implementation of the second phase of the approach proposed in [4] 

should help in the analysis, because this would be conducted on truly concurrent 
models given by stochastically timed Petri nets, instead of interleaving models. 
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